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Booth No. 1040, sponsored sessions 
are on March 10 and 11, 4-5 pm. Booth crawling 


is also compulsary, so come and have a drink on us. 


Asacomprehensive solution = =—so—provides a data management 
environment that tracks the content of your game, from creation to 
delivery. Version control, file sharing, annotations, searching, process 
automation and status tracking are just some of the features that allow 
your team to be as productive at the size of 20 as they were with 5, and 
work with 100,000 files as well as they did with 5,000. 
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32 All Aboard Hardware T&L 


New graphics chips like the GeForce 256 accelerate 
transforms and lighting operations in hardware, 
allowing game scenes to be more visually complex 
and realistic. Fosner looks at hardware-accelerated 
T&L, explains what’s involved from a game develop- 
er’s perspective, and dives into the nuts and bolts of 
cubic environment mapping. 


BY RON FOSNER 


How to Simulate a Ponytail, Part 2 


After leaving you hanging last month, Hecker winds 
up his series on open loop dynamic chains. Taking all 
of the tricky math and physics he had introduced, 
Hecker plugs and chugs, and out comes the basis for a 
realistically behaving ponytail. 
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BY CHRIS HECKER 


Postmortem: ASHERON'S CALL 


Creating a massively multiplayer game from the 
ground up with a team of uninitiated game designers 
sounds like a crazy idea. Teamed with Microsoft, the 
start-up crew at Turbine made modular architecture 
and dynamically load-balancing servers work like 
magic in ASHERON’S CALL. 
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Graphic Content BY JEFF LANDER 
Lights... Camera...Let’s Have Some Action Already! 


Artist’s View BY MEL GUYMON 
Skin Deep 2: Implementing Patch Surfaces 


Soapbox 
A Tale of Two GDCs 


BY NOAH FALSTEIN 
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7 Bit Blasts es 
Find Impulse’s Illusion revealed, 

_ together for the PS2 launch, and Jeff 
revisits Digimation’s MultiRes Mesh. 








\ gen gan 


-. Depicting a valiant battle between a samurai knight 
and an orthlio from ASHERON'S CALL, this scene was created 
by the Turbine art team. For more information visit : 
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One Year Later.... 


t’s difficult to believe that nearly 

one year ago the Columbine 

High School killings took place. 

In the wake of their violence, our 
industry (not to mention other media 
sectors) experienced close scrutiny from 
every corner in an attempt to establish 
a cause-effect relationship with this dis- 
aster. Today, we’re still no closer to 
understanding the cause of that ran- 
dom violence, and I suspect we'll never 
know what motivated gunmen Harris 
and Klebold. However, despite all of the 
unanswered questions, I’ve been heart- 
ened by the way our industry has con- 
tinued to evolve and shoulder the 
responsibility that is ours to carry. In 
the past year we neither compromised 
our artistic game design ideals, nor did 
we sit back uninterested. Instead, the 
industry continued to defend the rights 
of developers to express themselves 
while improving the ways that it alerts 
the public (parents in particular) about 
the content of games. 

For me, the most affirming event of 
the past year was watching Doug 
Lowenstein, Chairman of the Interac- 
tive Digital Software Association, share 
the stage with Sen. Joseph Lieberman 
(D-Conn.) on C-SPAN and detail the 
strides that the industry made to 
improve the effectiveness of the Enter- 
tainment Software Ratings Board’s rat- 
ings system, including expanded efforts 
to educate retailers and parents around 
the United States about the system. 
Lieberman, a longtime critic of violent 
videogames, was as upbeat about our 
industry as I’ve ever seen him. 

Another point of progress over the 
past year was the ESRB’s establishment 
of a new arm called the Advertising 
Review Council (ARC), charged to 
“ensure that advertisements placed by 
U.S. computer and videogame software 
makers are appropriate, responsible, 
truthful, and accurate.” The ARC was 
announced in October, but the seeds of 
its creation really go back to 1998. 
Commenting on the ARC’s establish- 
ment, Lieberman stated, “I want to 
applaud the videogame industry for 
taking seriously the concerns that were 
raised in the wake of Littleton and try- 
ing to do something about them. These 
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measures, taken together, are a real ges- 
ture of responsibility, and an important 
step forward in our ongoing efforts to 
help parents protect their children from 
the harms of digital violence.” 

On one hand I’m glad to see Lieber- 
man acknowledge our efforts, but I also 
believe that in the absence of Colum- 
bine and other senseless tragedies, we 
would have taken the same course of 
action. At last year’s E3 I talked to 
many developers who felt the same 
sadness as the rest of country. These 
developers, like the vast majority of 
people in our industry, genuinely care 
about the effect that games have on 
children. Because of this, I’m confident 
that our progress in the areas of ratings 
and advertising are the result of our 
commitment to responsible actions, 
not knee-jerk reactions to violent 
events or political pressure. It’s about 
us acting responsibly, and it makes me 
bullish about our future. 


ApiEu, Omip. It’s with regret that I bid 
columnist Omid Rahmat goodbye from 
the magazine. Omid has defected from 
our ranks to join Expertcity.com, where 
he’ll be heading up business develop- 
ment efforts. We’ll miss Omid and wish 
him all the best at his new .com job, 
and most of all we hope he remembers 
us when he’s flush with IPO cash. 


HELLO, CMP. You may have noticed a new 
logo on the upper left-hand corner of 
this month’s cover. What’s this “CMP” 
you ask? Last year the parent company 
of this magazine, Miller Freeman, 
acquired the large high-tech publishing 
company CMP Media, and beginning 
this month Game Developer will be pub- 
lished under the CMP brand. The CMP 
moniker will also attach itself to the 
other products and services we provide 
to the game development community, 
including the Game Developers Confer- 
ence, Gamasutra.com, the GAMEX- 
ecutive Conference, the GDC HardCore 
Technical Seminars, and the Indepen- 
dent Games Festival, so you may seeing 
it quite.a bit from now on. & 
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Stop the Game, | Want to Get Off 


always enjoy reading the Postmor- 
tems in Game Developer to see the 
mistakes developers make, and also to 
get a window into the work practices of 
other games companies. In the Post- 
mortem of AGE OF KINGS (January 
2000), Matt Pritchard told us that 
developing the prequel AGE OF EMPIRES 
involved “working nonstop” for six 
months, which “took a heavy toll on 
people,” so that the company decided 
to try to avoid this for AGE OF KINGS. 
The way they tried to improve thin: 
was by spreading out the crunch ti 
and during crunch working 10 A. 


| Is it just me or does this still so 
pretty bad? I guess doing th S 
week, or maybe two, would 
bad, but to do it for any lo 
ods, and repeatedly, sound 
Working these hours will s 
marriage, your family, and y 
ships outside work. To attract 
more experienced or specialist st 
(who are often older, married, and h 
families), this would not be a recom- 
mended working practice. 
As you work longer hours over pro- 
longed periods you become weary and 
the quality of your code deteriorates. 
When games were smaller projects 
with one or two programmers, the 
quality of your code wasn’t so impor- 
tant, you could just cobble it together. 
On larger projects as games are now, 
sloppy code will leave you increasingly 
drowning in bugs as you struggle to 
make headway at the end of your pro- 
ject which is “almost finished.” These 
long hours will stretch your team rela- 
tionships and tensions may develop, 
leading to unmotivated (and therefore 
less productive) staff, and people might 
start to leave. As an industry, can we 
please leave these barbaric and coun- 
terproductive methods behind? 
Dr. Paul Tapper 
Infogrames 
via e-mail 


Don't Gamble on Our Artistic Vision 


must come down firmly against con- 
tent in Game Developer like Steve 
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Boelhouwer’s “Playing for Keeps: 
Developing Casino Games” (January 
2000). The obvious rationale for 
including an article on gambling 
devices in the magazine is that they’re 
games themselves, running on com- 
puters. This is where I think we need to 
be careful. The two industries 

(arcade gaming 
and slot 
machines) 
make differ- 
ent choices as 























look in environments for game 
creation and say how much room for 
artistic innovation they offer. 
Therefore, I feel pretty comfortable 
saying that developing the digital con- 
tent for slot machines doesn’t offer a 
very artistically fertile environment. 
(Note that I don’t mean this in the 
graphical sense; graphically the slot 
machines are quite beautiful, | mean 
this in the sense of the game itself.) 
You have fairly ironclad bounds on 
how the game plays and works, and it 
corresponds to a fairly mundane sys- 
tem with a rather limited control set. 
Plus, you’re catering to an audience for 
whom the maximum requirement is 
that they be able to put quarters in a 
slot; requiring these people to be capa- 
ble of ten-move combos, fast reflexes, 
deep puzzle-solving, or army micro- 
management is a losing proposition. 
So you could ask, “So what? Why 
can’t the magazine talk about opportu- 
nities that maybe aren’t very innovative 
and don’t offer much room for expres- 
sion as game designers? It still offers 
opportunity, what’s the problem?” 
Here, I’ll admit that I’m making some 
value judgments. But those value judge- 
























We'll lend you an ear. E-mail us at 
editors@gdmag.com. Or write to 


Game Developer, 600 Harrison Street, 
San Francisco, CA 94107, 


ments boil down to this: I want Game 
Developer to be a magazine about inno- 
vation and advancement in game devel- 
opment. In times where there’s such a 
push to drive our industry to crass com- 
mercialization, I think it’s important to 
keep focused on the artistic qualities of 
our industry. You know, the qualities 
that keep us here instead of in 
other computer industries 
where the jobs are a little 
more secure and the 
pay’s better. I’m not say- 
ing that money is evil, or 
that we should all wear 
berets and smoke cigarettes 
out of those stylus things. I’m just 
saying that unless we keep focused on 
the aspects of this industry that tran- 
scend money as an attractive force, our 
industry will eventually become a 
generic field of computing (just one that 
happens not to pay as well as others). 
Brian Sharp 
via e-mail 


AUTHOR STEVE BOELHOUWER RESPONDS: 
My purpose in writing this article was to shed 
light on an industry segment which many 
game development professionals may be 
only casually familiar with. You are correct 
that the design parameters and objectives 
for electronic gambling devices can be quite 
different from those of other game genres, 
just as an RPG has drastically different objec- 
tives from those ofa first-person shooter. As 
a longtime reader of Game Developer, / enjoy 
coverage of all of these genres, and would 
be disappointed if the publication were to 
narrow its focus and exclude certain aspects 
of our industry. You touched on career 
opportunities; this being a trade magazine 
(as opposed to a publication for game fans), 
| for one would like to continue to read about 
areas where our Skills may be of value. 

With respect to the degree of innovation 
and “artistic fertility” possible in the indus- 
try, | would again opine that this is simply a 
function of the design parameters and 
objectives. The design and technology in 
modern gambling devices are more complex 
than perhaps you are aware. Furthermore, | 
disagree that “these people” (your descrip- 
tion of casino patrons) are somehow inca- 
pable of enjoying advanced game-play fea- 
tures. In fact, a key design goal for the 
future will be to incorporate innovative fea- 
tures while still maintaining the fun and 
excitement of the gambling experience. We 
would welcome talented professionals such 
as yourself to join us in this task. 
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HavOKconm 1s te game technology wing of Telekinesys Research Limited. 
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WARNING 


TAKE ONE PER GAME FOR PHENOMENAL PHYSICAL EFFECTS 


VISUAL AND AUDITORY HALLUCINATIONS - COLD SWEATS - MEMORY LOSS - PALPITATIONS - CONFUSION - MENTAL DETACHMENT 
EUPHORIA - NUMBNESS OF THE EXTREMITIES - PURPOSELESS MOVEMENT - SENSE OF WELL-BEING - INCREASED LEVELS OF SEXUAL DESIRE 












: Onli one 3D game engine has what it tak 
fast track trom — 1; NetImmerse from ND 










“With NetImmerse, we can concentrate on the design of the game itself, 
reducing production time.” — Mark Jacobs, Mythic Entertainment 


““NetImmerse allowed us to focus our energies on the content 
elements a set Panzer General 3D Assault apart from the 
- Dan ERAN, Mindscape 












ation® 2, MacOS, and Linux. 







oe We are taking advantage of a broad range of 
features, including skinning for natural-looking 

_ characters, and continuous level of detail, dynamic 
 multiple-color lighting, and multitexturing to create 
_ rich environments.” - Jean-Noel Portugal, Dramaera 











“the seen for a game- 
related SDK, by a wide margin.” — Jonathan Blow, Game 
Developer Magazine 


“Support is always prompt. Usually the person who wrote the software 
in question is available to provide answers.” — Bob Case, AniVision 


Contact NDL today to find out about the fastest path 
from 3D game conception to completion. 





www.ndl.com 
650-328-4388 
sales@ndl.com 
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by Daniel Huebuer 


Pixel Prestidigitation 


IMPULSE’S new Illusion: The Magic of 
Pixels is a particle effects system and 
compositing tool that aims to combine 
maximum control with absolute ease 
of use. Illusion allows users to work in 
a 2D environment with a WYSIWYG 
display showing what is going on dur- 
ing all work stages. 

The key to Illusion’s speed is its use 
of images to simulate a larger number 
of particles, reducing calculation and 
rendering time. Users can even use an 
.AVI or a series of images to create ani- 
mated particles. 

Effects can be added by selecting a 
specific effect from Ilusion’s emitter 
libraries and placing it on the stage. 
Many emitter properties can be manip- 
ulated directly from the main work- 
space, and low-level properties can be 
accessed through an emitter properties 
dialog while still providing a real-time 
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Illusion’s self-styled “WYSIWYG” interface offers real-time 
previewing of particle effects in a 2D environment. 
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preview of the changes. Illusion sup- 
ports multiple layers and other func- 
tions to integrate effects easily into a 
3D environment. 

Illusion: The Magic of Pixels is 
priced at $249 and runs on Windows 
95/98/NT 4. An OpenGL accelerator is 
recommended. 

@ Impulse Inc. 

Las Vegas, Nev. 

(702) 948-1100 

http://www.coolfun.com 


Nichimen’s High Hopes for the Future 


MIRAI is Japanese for “prosperous 
future,” and Nichimen Graphics has 
upgraded its modeling and animation 
software package of that name to 
ensure it meets its lofty goal. Mirai 1.1 
is the next evolution of Nichimen’s 
suite of real-time content creation 
tools, which replaced N-World as Nichi- 
men’s flagship package upon its origi- 
nal May 1999 release. 

Mirai 1.1 contains enhancements to 
the render speed, display, and I/O of the 
original Mirai. The upgrade offers com- 
plete support for Game Exchange 2.1 as 
well as improved 
export to .OBJ 
and .3DS file for- 
mats. Geometry 
enhancements 
include addition- 
al default model- 
ing options, 
improved camera 
manipulation, 
and magnet 
move multiple 
vertices on nor- 
mals with falloff. 
Skeletal anima- 
tion advances 
support magnet 
operations, 
squash and 
stretch, root rota- 
tion, and new 


New Products: Impulse introduces 
Illusion for particle effects, Nichimen 
upgrades Mirai, and Criterion offers a 
Maya plug-in for Renderware 3. p.7 


Industry Watch: Sony consolidates 
in preparation for the PS2 launch, 3dfx 
trims the fat, and Monolith spins off 
Lithtech Inc. p. 8 


Product Update: Jeff Lander reports 
on what Digimation and Intel have 
been up to since he reviewed the Multi- 
Res Mesh in November 1999. p. 10 


display options and deformer icons. 
Mirai 1.1 includes support for additional 
domains including Sony, N64, and 
Dreamcast, and supports attribute trans- 
lation between domains. 

Mirai 1.1 is available for IRIX 6.3 or 
higher and Windows NT 4. It is priced 
at $6,495. 

@ Nichimen Graphics Inc. 

Los Angeles, Calif. 

(310) 577-0500 

http://www.nichimen.com 


Breaking Down Development Barriers 


CRITERION SOFTWARE has announced a 
new plug-in for Renderware 3 that can 
export world, object, and animation 
data created in Maya. Available for 
both PC and Playstation 2 platforms, 
the plug-in allows developers to build 
game levels and characters using a 
completely integrated package, model- 
ing and animating in Maya while 
using Renderware 3 as the run-time 
engine. 

The Maya exporter plug-in allows 
users to export entire 3D game worlds, 
complete with UV texture coordinates 
and vertex prelighting. The plug-in 
can also export textured objects and 
animations. Supported animation 
types include morph target, keyframe, 
animation sequence, and Renderware 
3’s proprietary “skin and bones” for- 
mat. Criterion plans future support for 
Maya’s procedural materials, skinning 
and weighting tools, and motion cap- 
ture data in an upcoming version of 
the exporter plug-in. 

The Maya exporter plug-in for Ren- 
derware 3 is included as part of the 
standard Renderware 3 SDK at no addi- 
tional charge, and complete source 
code is provided to allow users to cus- 
tomize the tool. 

@ Criterion Software Ltd. 

Guildford, Surrey, U.K. 

+44 (1483) 406233 

http://www.renderware.com 
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ia) Industry Watch 


by Daniel Huebuer 


SONY CONSOLIDATES. In preparation 
for the upcoming Playstation 2 launch, 
Sony Computer Entertainment of 
America is making moves to consoli- 
date its operations. SCEA will merge 
spin-off developer and publisher 989 
Studios into Sony Computer Entertain- 
ment America. Kelly Flock is due to 
step down as 989’s president April 1, 
and leadership of the studio will fall to 
SCEA’s management team with Kazuo 
Hirai as president and CEO of the 
entire North American operation. In 
addition, Shuhei Yoshida will join the 
merged organization as vice president 
of product development. 


3DFX STREAMLINES. As part of an 
aggressive program to return to prof- 
itability, 3dfx Interactive announced 
approval of a plan to spin off its Spe- 
cialized Technologies Group (STG) and 
reduce the company’s overall workforce 
by 20 percent. The STG, which focuses 
on commercial multi-channel video 
and display, accounts for some of the 
workforce reduction, while other reduc- 
tions will come from layoffs and attri- 
tion in redundant areas. Most affected 
will be 3dfx’s administration, opera- 
tions, sales, and software support 
departments. CEO Alex Leupp said the 
measures will help put the company in 
a more favorable position for its new 
fiscal year, which began January 1. One 
notable departure is the retirement of 
Bill Ogle from his position as executive 
vice president and vice chairman of 
3dfx’s board of directors. Ogle joined 
3dfx as part of the company’s 1999 
merger with STB Systems, which Ogle 
co-founded in 1981. 


MATTEL RESIGNATION. Mattel CEO Jill 
Barad resigned after failing to stem the 
decline of the company’s sales and 
profits. Barad announced her resigna- 
tion after Mattel announced its fourth- 
quarter losses in February. The compa- 
ny posted a net loss of $18.4 million 
on sales of $1.77 billion. Mattel had a 
net profit of $86.7 million on sales of 
$1.82 billion in the same period last 
year. Barad took the top job at Mattel 
in 1997 and oversaw Mattel’s struggle 
with last year’s $3.5 billion acquisition 
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The Lithtech engine is getting its very 
own company spun off from Monolith. 





of The Learning Company. Mattel 
board members William Rollnick and 
Ronald Loeb took on the respective 
roles of acting chairman and acting 
chief executive as the company under- 
took its search for a new CEO. 


MONOLITH FOUNDS LITHTECH INC. 
Monolith Productions has announced 
a technology spin-off, Lithtech Inc., 
dedicated to the creation of real-time 
3D development and networked multi- 
media operating systems. The company 
will become the caretaker of Mono- 
lith’s Lithtech 3D engine technology 
licensing program, and has named 19- 
year Microsoft veteran Gregory Whit- 
ten as chief software architect. “Lith- 
tech Inc.’s ability to attract someone of 
Dr. Whitten’s caliber confirms our 
belief that our technology implementa- 
tion is state-of-the-art,” said Monolith 
Productions CEO Jason Hall. 


SORENSEN LEAVES LUCAS. Jack Soren- 
sen has stepped down as president of 
LucasArts Entertainment. At the time 
Sorensen made the announcement in 
February he did not specify what his 
future plans would be, saying only 
that he would take some time to work 
through his opportunities. The Lucas- 
Arts board in turn promoted Simon 
Jeffery from his role as product devel- 
opment director to replace Sorensen 
as president. Jeffery joined LucasArts 
in 1998 to help expand the company’s 
international business. “Former presi- 
dent Sorensen shaped the company’s 
strategic direction, and | credit him 
with building LucasArts into one of 
the world’s leading developers and 
publishers of interactive entertain- 
ment software,” said LucasArts board 
chairman George Lucas. Sorensen’s 
resignation follows closely on the 





heels of other high-profile departures 
from the company, including that of 
designer Tim Schafer. The LucasArts 
board also appointed May Bihir to the 
newly created position of vice presi- 
dent of worldwide sales and named 
Lucasfilm executive vice president 
Micheline Chau as lead director of the 
LucasArts board. 


DAVIES DEPARTS DIGITAL ANVIL. Digi- 
tal Anvil president Marten Davies left 
the firm February 1. Digital Anvil had 
originally envisioned itself as an inde- 
pendent publisher, but consolidation 
in the industry led the company to 
pursue development, leaving Davies 
with a less obvious place in the com- 
pany’s plans. Davies commented upon 
his departure that he had “enjoyed the 
challenge of assisting the company in 
laying the foundation stones for its 
current and future success,” but he 
was “unable to bring any more imme- 
diate value to the equation.” Digital 
Anvil’s founder and chairman Chris 
Roberts said that the company would 
not name a successor; rather, it is 
dividing Davies’s responsibilities 
among other members of the execu- 
tive team. @ 
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Digimation s Real- 
‘Time 3D Libraries 


_by Jeff Lander — 


n November 1999 in this very 
space, I took a look at the MultiRes 
Software Toolkit from Digimation. 
This product was created at the Intel 
Architecture Labs. And no, the gang up 
at Intel hasn’t spent the last few 
months hunkered down in their Y2K 
bunkers. They have been cranking 
away on some great 3D technology. 
This toolkit expands on the automat- 
ic level-of-detail (LOD) technology of 
the original toolkit by adding modules 
for subdivision surfaces, non-photore- 
alistic cartoon rendering, skeletal char- 
acter animation, and particle systems. 
These modules have been integrated 
into a single 3D rendering system. A 
sample application allows you to try 
out the various settings in each render- 
ing module. These settings can then be 
used in your game project to achieve 
the same effect. Each module is sold as 
a separate license so developers can 
pick and choose only the pieces they 





FIGURE 1. Subdivision surface sample. 
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really need for production. 

MULTIRES 2. MultiRes 2 implements a 
continuous level-of-detail system for 
3D objects. This system allows game 
programmers to dynamically scale the 
number of polygons in a model up or 
down to achieve the ideal speed vs. 
quality ratio for any rendering sce- 
nario. For example, when a character is 
farther away from the camera, the 
number of polygons can be reduced 
significantly, thus lowering the time 
needed to render that character. With 
the ability to adjust the polygon count 
of an object in continuous steps, the 
MultiRes system avoids the annoying 
“popping” effect seen when a model 
with a small number of discrete levels 
of detail is used. 

The MultiRes Mesh component in 
the toolkit is largely unchanged from 
when I last looked at the package. The 
API has been changed slightly to inte- 
grate with the other pieces of the 
toolkit. 

SUBDIV RT. The first new feature in the 
toolkit is a subdivision surface system. 
If you followed Brian Sharp’s two-part 
series on subdivision surfaces (January 
and February 2000), you are already 
aware that this technology allows you 
to dynamically increase the complexi- 
ty in a simplified basic mesh. This 
works by adding triangles to fill out 
the detail in a base mesh. For exam- 
ple, it will smooth out a curve by pro- 
gressively adding more triangles to the 
object. 

You can see this in Figure 1. In the 
simple low-resolution base mesh on 
the left, the detail is progressively 
added in the center mesh, achieving a 
halfway-point mesh and then finally a 


very detailed final model, shown on 
the right. 

Using the SubDiv RT toolkit, you 
have a great deal of control over the 
subdivision method. One option is to 
decide to subdivide the mesh uniform- 
ly, so an equal number of triangles is 
created for each triangle in the original 
mesh. Another option is to use adap- 
tive subdivision where the mesh 
divides to a level based on a user-sup- 
plied metric. 

An interesting application for subdi- 
vision surfaces is using this technology 
in combination with the MultiRes sys- 
tem for online applications. In an on- 
line game situation, when a unique 
character is encountered, it may be 
necessary to download geometry for 
that character. By using subdivision 
surface technology, a very simple base 
mesh could be downloaded immediate- 
ly to the user. This could be subdivided 
adaptively to make a nice-looking 
mesh. While this mesh is used, a high- 
er-resolution MultiRes mesh can be 
downloaded in the background. Once 
it is available, the system can switch to 
the MultiRes system and use all that 
artist-created detail directly. 

BONES RT. This package offers a real- 
time skeletal deformation system that 
can be used with both of the above 
rendering technologies. Using this sys- 
tem, a base mesh is deformed by a 
user-provided skeleton. The Bones RT 
toolkit provides algorithms to refine 
the weight system that attaches the 
skin to the skeleton. The user ani- 
mates this skeleton and the Bones RT 
system deforms the skin automatical- 
ly. By using quaternions to represent 
the orientation of each bone in the 
system, the animation 
frames can be interpo- 
lated smoothly to create 
nice in-between frames. 
You can see a sample 
creature with an embed- 
ded skeleton along with 
the skeleton control 
dialog in Figure 2. 

One interesting addi- 
tion to the skeletal sys- 
tem is the use of what is 
called BoneLinks. These 
are mini-bones that are 


SSS SSS SY 


“Jeff has been writing way too much tava to ha mer to come up with a clever bio. Show him up by sending him something funny 


ee 


aL ee 
En aT 


http://www.gdmag.com 


© 2000. MOTEK Motion Technology Inc. MOTEK, the MOTEK loge. and UNICA are trademarks of MOTEK Motion Technology tnc. 






MOTION CAPTURE ANIMATION 
TAKES AN EVOLUTIONARY 
STEP FORWARD. — 
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603-641-1300 
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Sophisticated motion capture for 
every production budget has 
arrived. MOTEK introduces UNICA’’ 
the web-based animation solution 
that lets you rapidly custom-build 
and blend data sets from the 
world’s largest motion capture 
library, view a preview, then 
purchase and download — at 
one-tenth the cost of original 
production. With UNICA, the world 
of motion capture is at everyone’s 
fingertips. Come play on our site 
right now and watch your 
imagination take shape right in 
front of your eyes. 











inserted between each bone at the 
joint to combat the problems of pinch- 
ing and twisting that sometimes occur 
at skeletal joints. 

RENDER RT. The Render RT module 
allows you to use non-photorealistic 
rendering techniques with a mesh gen- 
erated by any of the other object tools. 
This module incorporates all of the 
ideas I discussed in my March column 
on cartoon rendering (“Shades of 
Disney: Opaquing a 3D World,” Graph- 
ic Content, March 2000). Render RT 
detects silhouette edges as well as the 
edges defining material borders. These 
lines can be drawn with different col- 
ors, different thicknesses, and with or 
without antialiasing. The characters 
can then be shaded using different 
paint styles. The classic cartoon style 
allows you to define a shadow, high- 
light level, and threshold. This shading 
is applied to the base material color to 
create the “toon” look. 

Beyond the cartoon shading, howev- 
er, Digimation has added a sketch style 
that applies line textures to the object 
so it looks as if the character has been 
sketched. This is a multi-pass method 
that requires more rendering time, but 
it really looks different from traditional 
computer graphics, as you can see in 
Figure 3. 

PARTICLE RT. The last module in the 3D 
Toolkit handles particle-system ren- 
dering. Unlike the other modules, this 
system doesn’t really work directly 
with the other technologies but is 
more of a stand-alone particle system 
API. The API allows the user to con- 
trol the generation, behavior, and 
look of the particles in the system. 
Forces can be created that interact 
with the system, such as wind and 
gravity. The particles can be con- 
strained to follow a path and you can 
also create collision boundaries for the 
particles. By applying textures to the 
particles and controlling the scale 
dynamically, a great variety of effects 
can be achieved. 

TOOLKIT SDK. The key feature of this 
toolkit is its API. The API allows devel- 
opers to use this technology in their 
own projects. As with the MultiRes 
Mesh Toolkit, all of the run-time 
source for each module is included, so 
you can integrate the package easily 
into your own productions. 

Each module also includes a sample 
viewer with source code along with 
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documentation for both the API and 
the viewer. 

PLUG-IN FOR 3D STUDIO MAX. To generate 
content for these systems, there is an 
export plug-in for 3D Studio Max. The 
plug-in allows you to define the API 
export parameters through a control 
interface. For users who do not work 
with Max, the API creation routines can 
be used with your own custom tools. 
THE BOTTOM LINE. The Digimation Real- 
time 3D Libraries are a sophisticated 


Digimation Inc. 
St. Rose, La. 


(800) 854-4496 
http://www.digimation.com 


Software Requirements: 
3D Studio Max for the plug-in; 
Windows 95/98/2000/NT 4.0; 
Run-time code is portable to other 
platforms. 


Digimation’s Real-Time 3D Libraries with 
Intel Scalable 3D Graphics Software Technology: 
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The Render RT module adds a sketch effect to cartoon shading for a 





collection of technology, and the 
source code is ready to be incorporated 
into a variety of 3D projects. It marks a 
significant enhancement of the origi- 
nal MultiRes 3D Toolkit. Each module 
is licensed separately so you are not 
required to buy something you are not 
going to use. If you are developing a 
3D game project that requires cutting- 
edge 3D technology and looking for a 
head start, you should certainly check 
it out for yourself. @ 





_ Pricing: Each module price is given per 


finished game title. 


_ MuttiREs 2 RT: $10,000 including three 


copies of the Max plug-in. 


~ SuBDiv RT: $10,000 
_ Bones RT: $10,000 


RENDER RT: $5,000 


PARTICLE RT: $5,000 


MULTIRES 2 PLUG-IN FOR 3DS MAx: was 
$295, currently priced at $99 
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If only someone could give me 
a tool that would let me design 
fast network games with drastically 
reduced development time and cost 
so I'd be free to express my 
creativity to its fullest potential 
and improve my time-to-market, 


then I'd be happy. 








I'll smile now! 


We've got what you've been dreaming of. Introducing NetZ, a powerful new toolkit for 
creating high-performance, multi-player network games. Sure to put a smile on your face. 
Because with NetZ minding the network, you get to spend your time on game design. 
NetZ gives you fault-tolerance, load balancing and dead-reckoning right out of the box. 
Internet game design just got a whole lot easier. 


[ Proksim] 


Shaping the online future 
‘Phone: (514) 940-9090 info@proksim.com www.proksim.com | 
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Call today to see how an in-house motion capture system 
from Ascension can work for you. Ask for our free demo reel! 
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by Jeff Lander 





Lights...Camera...Let’s Have 
Some Action Already! 


XT. STREET — NIGHT — WIDE HIGH ANGLE 
Camera tracks BURKE as he walks down rain-drenched street. Light foot 


traffic. BURKE nods to a doorman and continues, turning right on 





Catalina Street. 


CUT TO: 
EMPTY SIDE STREET — MED. FULL 


Camera tracks BURKE walking slowly 
up Catalina. Footsteps can be clearly 
heard following. BURKE notices and 
eyes dart but does not turn. Shot 
widens as he continues up street. 
ROCCO enters frame following BURKE 
casually strolling along smoking. 
BURKE turns to a stop in front of a 
restaurant, “examining” the menu. 
ROCCO comes to a stop in a doorway, 
puts out his cigarette with his shoe. 


CUT TU 
REVERSE — OTS TWO SHOT — MED. 
FULL 


BURKE turns continuing down street. 
ROCCO starts to follow again. BURKE 
grimaces as footsteps resume. Camera 
tracks ahead of BURKE showing 
ROCCO over shoulder. Continues lead- 
ing him until he comes to a newsstand. 
He stops and turns to pick up and 
examine a paper, footsteps slow behind 
him coming to a stop. 


CATT TOs 
MED. CLOSE — BURKE 


He picks up a magazine, eyes alert. Try- 
ing to catch a glimpse of his pursuer to 
his right out of the corner of his eye. 
Suddenly a hand grabs his left shoulder. 
He jumps. 
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TWO SHOT — BURKE AND STAND 
OWNER 


STAND OWNER 
I’m not running a library here, 
Mac. That’ll cost you a nickel. 


BURKE takes a beat, tucks the paper 
under his arm, and tosses the man a 
coin. Turns to continue down street. 
Footsteps continue behind him. He 
quickens his pace. The footsteps quick- 
en. He breaks into a run. His pursuer 
starts to chase. 


ULTRAVIOLENT — TERRIBLY FASCI- 
NATING STORY BEGINS... 


From Big Screen to Game Screen 


ll right, so it’s a cliché action 

sequence. I’m a programmer and 
this is not my latest screenplay. But 
that’s not the point. A quality director 
can take these simple ideas and create 
tension, drama, and anticipation. These 
are exactly the qualities that pull people 
into a story. However, in interactive 
game applications, generating feelings 
of tension and drama is very difficult. 

It’s easy enough to create a cinemat- 

ic cutscene that follows traditional 
filmmaking techniques. However, this 
yanks the player out of the interactive 
experience. Modern 3D game engines 
can create cinematic sequences within 
games, but most of the time these 


a monkey at Darwin 3D, but what he real- | 
_ ly wants to do is direct. When not out pitching his latest spec script, he can be 











sequences are completely scripted 
using traditional animation tech- 
niques. The sequence fires when the 
player enters a location, pulls a lever, 
or triggers some other mechanism. 
Once started, the sequence follows a 
deterministic path. The game designer 
now has a choice to make. The first 
option is to control the camera shots 
to show the drama, suspending the 
interactivity. Second, the player can 
maintain complete camera control and 
try to catch the action. This can create 
a great sense of “What’s going on up 
there?” as you rush to find a view- 
point. HALF-LIFE used this technique 
very effectively. However, crucial 
information cannot be delivered in 
this manner as the player may miss it 
by spending too long studying the 
magnificent architecture. 

The ideal solution would be to pre- 
sent the drama to the character as 
much as possible while allowing the 
player full control. It’s clear to me that 
the camera system in a story-driven 
game needs to be a crucial character. It 
needs to be aware of what the player is 
doing, what is going on in the world. 
The camera needs to be “intelligent” 
enough to find the best viewpoint to 
show the player what’s going on with- 
out ruining the dramatic element. To 
address this situation, I’m going to 
explore the idea of “camera AI.” 





Smart Cameras 


ene game wisdom seems 
to hold that 3D real-time shooters 
must use a first-person camera while 
story-driven 3D action and adventure 
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| the first-person point of view 


| to rely completely on sound to 


games need to use a third-per- 
son camera. This may be the 
case. It is certainly true that 


(POV) is not an effective 
movie storytelling paradigm. 
If you get the chance to see 
the film Lady in the Lake 
directed by and starring 
Robert Montgomery, certainly 
check it out. It is a very inter- 
esting moviemaking experi- 
ment. Montgomery filmed 
almost entirely from a subjec- 
tive point of view. The only 
time you see the protagonist 
is in reflection. While com- 
pellingly different and not a 
bad movie in its own right, it 
shows dramatically why the 
first person is not the most 
effective method for convey- 
ing drama. 

Take the rough scenario | 
outlined at the beginning of 
the column. Played in the first 
person, I would hear footsteps 
and need to swing the camera 
around to catch what was 
going on. All the subtlety 
would be gone. My shadow 
would either simply be hidden 
when | turned, or be caught 
diving behind a wall, cover 
blown. Likewise, for the news- 
stand sequence, | would need 


convey the surprise from the 
stand owner grabbing my 
shoulder. While all these 
issues have solutions, the first- 
person POV certainly limits 
the possible options. With this 
in mind, let’s take a look at 
automated methods for third- 
person POV cameras. 


The Shooting Gallery 


T° begin with, I need to 
create a frame of refer- 
ence for all the shots I want to 
compose. Fortunately, many years of 
cinematography have provided a 
ready-to-use guideline for shot compo- 
sition. Let me start with the framing of 
a shot for a single person. Obviously, 
the simplest step would be to divide 
the shots into long, medium, and 
close. A long shot would include the 


FIGURE 2. The fish-eye effect can be an unintended result 
of incorporating too much width in the field of view. 
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Extreme Close-up 
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Med. Close-up 


Wide Close-up 
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Med. Full Shot 


Full Shot 


FIGURE 1. An array of commonly used terms for describing 
shot selection. 








character and the environment, a 
medium shot might be the character 
from the knees up, and a close-up 
would be just the head. 

This doesn’t really give the fine-grain 
descriptive terms that would be useful 
for framing a character. Typically, cine- 
matographers frame the human figure 


aN 
Full Close-up 





using nine basic shots. The 
terms I am going to use are: 

e Extreme close-up 

e Medium close-up 

e Full close-up 

e Wide close-up 

e Close shot 

e Medium close shot 

e Medium shot 

e Medium full shot 

e Full shot 

You can see the framing for 
these shots in Figure 1. Once 
defined, these different shots 
are easy to work with ina 
real-time 3D game scenario. 
The goals are to center the 
character on the screen at the 
proper distance for the vari- 
ous shots. The first thing to 
find is the camera target, 
where I am going to point the 
camera. I could track a series 
of focus points on each char- 
acter. Fortunately, I embed a 
skeletal system inside my 
characters so I can animate 
them. The base of each bone 
in my skeletal system is a 
ready-to-use focus point. | 
just pick the appropriate bone 
base to “look at” and use that 
as the camera target. For 
some of these shots, the focus 
point will be in between 
bones, but it’s easy enough to 
interpolate the position 
between them. 

Getting the right framing 
once I have the correct focus 
point is a bit trickier. I have 
two parameters I can play 
with. I can change the dis- 
tance of the camera to the 
character or I can change the 
field of view (FOV) on the 
camera, effectively zooming 
in or out on the character. | 
have found that game play- 
ers are very sensitive to FOV 
changes. If the field is too 
wide, the view takes on a 
fish-eye lens look (Figure 2) 
which can be very annoying (or cool, 
depending on your needs). If the field 
is too narrow, objects are hard to keep 
centered as subtle movements are 
exaggerated by the extreme zoom 
(think sniper rifle). So, I try to stay 
away from adjusting the FOV whenev- 
er possible. It’s much better to move 
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the camera. However, because we are 
in an interactive world, the players 
can move around into situations 
where the camera is in a tight squeeze 
and pulling back is not possible with- 
out breaking through part of the set. 
Here, a little zoom now and then is a 
good thing. 

So, using these simple guidelines, I 
started to create some “camera AI” 
routines. Given a character and a 
desired framing, the camera routine 
will start moving the camera to the 
desired position. This gives me the 
ability to say, “I’m ready for my close- 
up, Mr. De Mille,” and it happens — 


all without any keyframes or scripting. 


But monologues are not very exciting. 


Let's Strike Up a Dialogue 


dding a second charac- 

ter to the mix compli- 
cates things quickly. Let’s 
consider a scenario where a 
character walks up to another 
and starts talking. I start by 
tracking the main character 
with a full shot, as in Figure 3 
for example. 

As my character walks 
along, the other character can 
either approach me, or I can 
approach and start talking. At 
this point a dialogue is initiat- 
ed and I need to start consid- 
ering both actors in the scene 
as a pair. There is an imagi- 
nary line connecting the two. 
This line is actually very 
important as it defines a verti- 
cal plane that a camera cut 
between two cameras should 
not cross in most situations. I 
have seen several games and 
even some movies make this 
mistake. “Crossing the line” 
can really disorient the viewer 
because when a camera cut 
crosses the line, the relation- 
ship between the parties 
changes. The character on the 
right is suddenly on the left 
and your mind doesn’t imme- 
diately follow the motion 
path of the camera. 

I start off with an establish- 
ing shot that shows the spe- 
cial relationship between the 
two characters. If I’m lucky, 
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the standard single-player camera 
shows the character adequately and 
can be used as an establishing shot. If 
for some reason the view of the sec- 
ond character is blocked, the camera 
needs to swing around to frame both 
characters in the view. I just spin the 
camera around the key character until 
both are in view. At this point, I can 
set up my dialogue cameras. 

For two characters in a dialogue, | set 
up a bunch of virtual cameras that | 
can cut between while the dialogue 
takes place. All of these cameras are on 
the same side of “the line.” I decide 
which side to stay on based on the ini- 
tial positions, the direction each char- 
acter is facing, and the environmental 
restrictions. Usually, there is a pre- 
ferred side that is obvious given the 


"THE LINE" 


_ i F 


4 * 


FIGURE 3. Adding a second person requires careful shot 
selection to help viewers understand what is going on. 
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FIGURE 4. A camera setup for a two-person dialogue, offer- 
ing a variety of camera cuts for different moods and effects. 








conditions. The cameras | set up, 
shown in Figure 4, are: 

1. Group profile: camera perpen- 
dicular to the line, framing both 
subjects. 

2-3. Individual profiles: one camera 

framing each character. 
4-5. OTS: over-the-shoulder shots of 
each subject. 

6-7. Reaction shot for each subject. 

Now, that looks like a lot of cameras. 
However, one thing I always find 
amazing about 3D games is that cam- 
eras are so underutilized. From a tech- 
nical perspective, cameras are dirt 
cheap. A position, orientation, and 
field of view are all you really need. 
There is absolutely no reason for 
games to use the same camera, pan- 
ning, swiveling, and gliding every- 
where. Camera cuts are a very 
important part of storytelling. 
When was the last time you 
watched a film or television 
show that used a steady-cam 
following everyone around all 
the time? (Well, don’t count 
the opening sequence of 
Touch of Evil.) That is what we 
have currently in most games. 
(All right, mini-rant mode 
off.... Now back to our story.) 

Using the action line 
between the characters and 
the character positions, these 
camera positions are calculat- 
ed using simple 3D math. As a 
guideline, I have found that 
about ten degrees off the 
action line is good for the OTS 
cameras and 60 degrees is 
good for the reaction shots. 
The other cameras are just per- 
pendicular to the line. You 
remember how to take the 
perpendicular to a vector, 
right? (Big hint: Swap X and Y 
and negate one.) During the 
scene, the action line can 
move if the participants move. 
Anytime that happens, the 
cameras just get recomputed. 

Once all the cameras are 
set up, I need to determine 
which ones to use. This is 
where the camera AI comes 
in. The camera system needs 
to know about the characters. 
Who is talking? What’s the 
emotional state of each char- 
acter? For example, when a 
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Atari designed him to kill without mercy. 


We taught him to throw a nice curveball. 


w ww . V E Ww P O 


Meet the Green Jester—a fuse-happy fool with an explosive arsenal. When 
the other heroes from Atari’s hot new Gauntlet: Dark Legacy need some comic 
relief, this is the clown they turn to. And when the game’s production 

team needed to beat some crazy deadlines, they turned 


to Viewpoint. 


Having worked on previous Gauntlet characters, we were excited 
to create 3D models for Dark Legacy’s lead warriors. 
The bomb-licking Jester, however, seemed a little stiff. 


You see, his original design didn’t include any finger 


action, which meant his trademark toss looked...well, funny. 


“One of Viewpoint’s designers spent his day off building this 


skeleton for the Jester’s hand,” says Atari’s Scat Caterson, 


N T . C O M / A T A R 


the game’s art director. “We hadn't even spec’ed it that way, he just thought 


it would look more realistic. When we saw it, we agreed.” 


Atari has come to expect this kind of enthusiasm 
from Viewpoint. After all, we're not just a model 
shop—we’re a Strategic 3D Resource, used by more 
leading developers than just about anyone else. Hey, 
we taught this jolly green joker to throw like 
Q pro. Just think what we could do for you. 
Call 888-368-6073 or visit our website, and learn how you can 


get better 3D, with less fooling around. 


—  O'G,, 
* Viewpoint. 


A Computer Associates Company 


BEHIND THE SEEN 














character is talking, you probably 
want to use either the OTS camera or 
the profile camera that shows the 
speaker. While the character is speak- 
ing, you may occasionally want to 
switch to a reaction shot, particularly 
if the “mood” of the character dramat- 
ically changes based on the AI, script, 
or whatever. This is also where that 
real-time facial animation system you 
invested in earns its pay. Believable 
emotional reactions will really build 
the drama of the scene. 

I used a very interesting reference 
source (see “The Virtual Cinematogra- 
pher” in For Further Info) to set up a 
finite state machine that decides which 
camera to switch to depending on fac- 
tors similar to the above, as well as 
delay timers. Another very good idea 
they suggested is to prompt the AI of 
the characters to move a little if they 
are too far apart or are blocking the 
camera. Though I haven’t tried that yet, 


“nk © dol > owl iol Wal © est Gl a bal al © eel Jel bal cnt ©) 
e Bares, William, Joél Grégoire, and 
James Lester, “Realtime Constraint- 
Based Cinematography for Complex 
Interactive 3D Worlds.” Proceedings 
of the Tenth National Conference on 
Innovative Applications of Artificial 
Intelligence, Madison Wis., July 
1998. pp. 1101-1106. Available at 
http: / /www.csc.ncsu.edu/eos/users 
/\/lester/www/imedia/papers.himl. 
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e He, L., M. Cohen, and D. Salesin. 
“The Virtual Cinematographer: A 
Paradigm for Automatic Real-Time 
Camera Control and Directing.” Pro- 
ceedings of Siggraph. New York: 
ACM Siggraph, 1996. pp. 217-224. 


e Katz, Steven D. Film Directing: Shot 
by Shot. Studio City, Calif.: Michael 
Wiese Productions, 1991. 


More Research on Cartoon Rendering 
After my non-photorealistic render- 
ing columns in February and March, | 
got a note from Adam Lake, one of 
the researchers at Intel who is work- 
ing on NPR, He is presenting a paper 
at the Non-Photorealistic Animation 
and Rendering Symposium this sum- 
mer covering more advanced silhou- 
ette and shading algorithms. He has 
graciously made it available to the 

_ public. You can get the paper at 

__ http: //www.cs.unc.edu/~lake. _ 
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it certainly makes a 
lot of sense. 


Two's Company, 
Three's a Crowd 


E xtending this 
idea to more 
than two subjects 
complicates the 
setup quite a bit. 
For three people, a 
line can be estab- 
lished between two 
of the participants 
based on who is 
speaking and who 
is facing one FIGURE 5 
another. The gen- 
eral patterns for a 
three-person con- 
versation will fall into an “A” or “L” 
pattern depending on the layout of 
the participants and the action line 
chosen. In Figure 5, the people are in 
an “A” pattern leaving a nice action 
line between speakers A and C. How- 
ever, there are also valid action lines 
between the other players. So what do 
you do? You can always transition to 
the establishing shot to reset the 
group. In general, however, when the 
action line changes, there will be a 
valid camera that was on the same 
side as the previous line, so that 
should be the first choice. You can 
further complicate these groups by 
adding individual reaction shots. 
However, the basic alignment should 
provide enough options. 

For more than three speakers, it’s 
usually best to generalize the shots into 
group shots. You can create close-ups 
for the speaker and try to cut that with 
OTS shots from different sides of the 
group. Luckily for game developers, 
large groups of characters aren’t things 
we want a whole lot of anyway, for 
other reasons. 


Let the Player Have Creative Control 


veryone wants to be a director. 

This includes the game player. 
Most players will want to control the 
action. However, these techniques give 
the player a great deal of options 
beyond just spinning the camera 
around the key character, hoping to 


‘Establish 


Adding a third person complicates matters but 
shouldn’t disrupt the action if cameras are set up properly. 





find a good view. You can allow the 
player to jump through your possible 
cameras, modify the view once the cut 
happens, or take total control to pre- 
vent cuts. They could even assume a 
first-person POV, if desired. The point is 
to provide options that allow you to tell 
a story without locking the player out. 

Another interesting point is that the 
participants do not necessarily have to 
be people with whom the player 
speaks. When the player goes to pick 
up an object, open a door, or look at a 
painting, the object in view can 
become one of the subjects in the dia- 
logue. Looking over the shoulder of a 
character at a painting and then cut- 
ting back for the reaction shot would 
be very cool. Think of the AI reactions 
you could fire off. 

Our games are becoming more com- 
plex, and it is definitely time to start 
thinking about more sophisticated 
camera usage. Applying some of the Al 
techniques we have been using for 
characters to cameras certainly makes a 
lot of sense. As a bonus, experimenting 
with these sorts of camera routines is 
pretty fun. It’s amazing how you can 
begin to influence mood and pacing by 
manipulating very few parameters. & 
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by Mel Guymon 





Skin Deep 2: Implementing 
Patch Surfaces 


ast month we examined NURBS, patch, and subdivision surfaces as 
methods for creating real-time 3D characters. This month, we’ll pick up 


where we left off by putting the theory to practice and examining how 





to implement the patch surfacing method with RT3D geometry. 


As I discussed in my previous col- 
umn, there are many reasons to make 
the shift from polygonal modeling to 
one of the various surfacing techniques 
available to us. As the technology for 
processing and rendering 3D content 
continues to advance, so too does our 
ability to create realistic and engrossing 
3D content. However, to take advan- 
tage of the increased capability, the 
content we generate must be corre- 
spondingly more complex. More com- 


LOD1 
» High-Resolution 


Polygonal Model 


~ 


LOD 2 
LOD 3 etc. 


High-Resolution 
Polygonal Model 


FIGURE 1. Control point methodology. 





plexity means more polygons, and 
more time spent building, texturing, 
and animating them. In order to avoid 
ever-increasing development times, we 
as developers need to identify those 
processes that can be made “complexi- 
ty-independent.” That is, we need to 
evolve our content creation methods 
so that we feel free to increase the 
detail and diversity of our virtual 
worlds, and do so within our allotted 
development cycle. 


Surtacing Method 


Low-Resolution 
Primary Control Lattice 


LOD1 LOD2 LOD 3 etc. 
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| Mel Guymon has been animating in the gaming industry for several years. When he’s 
| not at his desk pushing polygons, he can usually be found at the local Barnes and 


can be reached at mel@infinexus.com. 
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In response to this, recall that last 
month we set out to define a process by 
which an artist could generate more 
complex models without spending too 
much time working with large amounts 
of data (Figure 1). In this ideal process, 
the artist, working only with a relative- 
ly low-resolution control point lattice 
and relying on a procedural method for 
extracting the high-resolution surface 
at the output, could generate arbitrarily 
complex models while maintaining a 
rapid and efficient workflow. To satisfy 
the requirements of this ideal process, 
we identified three potential surfacing 
methods: NURBS, patch, and subdivi- 
sion surfaces. Though all three of these 
methods met the basic criteria as out- 
lined in our ideal process, my choice 
turned out to be patch surface model- 
ing (for details on all three methods, see 
“Skin Deep: Surfacing Strategies for 
RT3D Characters,” Artist’s View, March 
2000). Right now, the best implementa- 
tion of patch surface modeling can be 
found in 3D Studio Max 3. 


Patch Modeling Basics 


H n Max, the patch surfacing tech- 
nique combines the best things 
about polygon-mesh and NURBS-sur- 
face generation. As is the case with 
polygonal modeling, artists can control 
the process at the very lowest level of 
data, and can create their surfaces one 
patch at a time if necessary. Once a 
patch is created, the tools for manipu- 
lating it and its subobjects (edges and 
vertices) are directly analogous to poly- 
gons. Patches can be extruded and tes- 
sellated, beveled, detached, and so on. 
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FIGURE 3. Cross-section example. 





As is the case with NURBS surfaces, the 
surface detail information is stored in a 
lattice of B-splines, whose curvature can 
be adjusted readily by a set of control- 
point tangent handles. Moreover, the 
surface resolution can easily be scaled 
up and down without affecting the 
underlying topology. Thus, smoothly 
organic shapes can be created efficient- 
ly, without the artist having to depend 
on complicated NURBS techniques or 
complex subdivision surfaces. 

All B-spline patch surfaces use as 
their building blocks patches generat- 
ed with three- or four-point polygons 
or splines. Figure 2 shows some exam- 
ple splines and the resulting surfaces. 
Note that in the third example, the 
spline lattice has not been completely 
partitioned into three- or four-point 
polygons. As a result, there are gaps in 
GAME DEVELOPER 
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the resultant patch 
| surface. This is due 
to the fact that in 
Max there are only 
two types of patch- 
es, tri-patches and 
quad-patches. Note 
also that with each 
increase in the 
number of steps, 
| the curvature of 
| each shape 
| becomes more 
| refined, as delin- 
| eated by the con- 
trol-point tangent 
handles. By using 
these control han- 
dles, the artist can create an almost 
limitless number of variations in the 
topology of the surface, all without 
ever increasing the density of the gov- 
erning control point lattice. 


Surface Tools 


he primary method for creating 
patch surfaces in Max is through 
the use of the Surface Tools. These 
include the Cross Section and Surface 
modifiers. The Cross Section modifier is 
used to connect a set of splines defin- 
ing the cross-section of a polygonal 
object. This is necessary because a 
spline lattice composed only of cross- 
sections has, by default, not been parti- 
tioned in the requisite three- and four- 
point polygons necessary for surfacing. 
In Figure 3, you can see an 
example of how this works. On 
the top left, we see a set of 
splines defining the cross-sec- 
tion of a human arm. Below 
that is the same set of splines 
after the Cross Section modifier 
has been applied. On the top 
right you can see a second 
example where the number of 
vertices in each cross-section 
differs. Below that, the Cross 
Section modifier has again 
been applied, though this 
process is somewhat hit-or- 
miss, since the modifier has no 
way of intelligently determin- 
ing where best to place the 
connecting splines. 

The Surface modifier converts 
a spline lattice into a patch sur- 
face by creating a patch at every 





point where spline segments intersect 
to form a three- or four-point polygon. 
For further editing, the resulting patch 
surface can then be modified with an 
Edit Patch modifier, which gives the 
artist access to the entire set of patch 
editing tools. 


Converting a Polygonal Mesh 
Directly to a Patch Surface 


Ithough the preferred method for 

creating a patch surface is 
through the use of the Surface Tools, 
it’s possible to convert an existing 
polygonal mesh to a patch surface 
directly. This is done by applying an 
Edit Patch modifier to a polygonal 
mesh, or by collapsing a polygonal 
mesh to an Editable Patch object. The 
main advantage of using this method is 
that any polygonal object can be con- 
verted into a patch surface. And since 
in many cases the data has come from 
an outside source (such as from a digi- 
tized model), the only current way to 
see the data is in polygonal form. 
Additionally, existing polygonal mod- 
els that were created before the artist 
had access to the patch surface method 
can be converted immediately to patch 
surfaces. Finally, the vast majority of 
RT3D artists have experience working 
only with polygons, and as such there 
may be a slight learning curve associat- 
ed with the Surface Tools process. 

The main disadvantage to this 

process is evident in Figure 4, where 


Surface Tools 
Method 


Polys to Patches 
Method 


FIGURE 4. Poly to patch method. 
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two surfaces with 
identical topology 
have been created. 
On the top we see 
a spline lattice and 
the resulting patch 
surface created 
with the Surface 
Tools method. On 
the bottom is a 
polygonal mesh 
and the resulting 
surface created by 
adding an Edit 
Patch modifier. If 
you look closely, 
you will notice 
that there are 
many more con- 
trol handles on 
the patch surface 
on the bottom 
right. This is because at every control 
point, the number of tangent handles 
corresponds directly to the number of 
edges intersecting that point. When the 
polygonal mesh is converted to a patch 
surface, the result is composed entirely 
of tri-patches. This results in a maxi- 
mum number of edges with a maxi- 
mum number of tangent handles, and 
the absolute least efficient surface for 
the corresponding geometry. 
Alternately, polygonal data generat- 
ed from an outside source can be used 





Example Flowpath: Stitching 
Two Surfaces Together 


ne problem that has always been 

hard to work around is how to 
connect two dissimilar organic sur- 
faces, such as an arm to a shoulder or a 
torso to a pair of legs. With patch sur- 
faces, however, the advantage comes 
in the fact that the source data is of 
extremely low resolution. In Figure 5S, 
we see two surfaces that need to be 
joined together to create a single con- 


so great, and the resulting advantages so 
significant, there is little question that the 
effort of learning the patch surfacing process 


SALSA INIA IO RS eH 





as a template on which a spline lattice 
can be built. This technique can prove 
to be much faster than one might 
think, since by using the 3D Snap 
tool, the spline network can be laid 
down very quickly. And though there 
is a learning curve associated with the 
Surface Tools method, in fact the simi- 
larities to polygonal modeling are so 
great, and the resulting advantages so 
significant, there is little question that 
the effort of learning the patch surfac- 
ing process is time well spent for any 
RT3D modeler. 
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is time well spent for any 3D modeler. 
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tinuous surface. Note, however, that 
where the two surfaces are to be 
joined, they differ in the number of 
vertices. To accommodate this, we'll 
need to create an in-between surface. 
With the 3D Snap function turned on, 
a spline lattice is created with an upper 
and lower cross-section corresponding 
exactly to the surfaces to be welded 
(top left). Then the cross-sections are 
connected with individual spline seg- 
ments (top center). Finally, a Surface 
modifier is applied, creating a patch 
surface which fits both the upper and 





lower surfaces (top right). These can 
now be welded together to create a sin- 
gle continuous surface. Alternately, we 
could have simply attached the two 
objects to each other and created the 
in-between patches one at a time by 
using the Add Tri or Add Quad func- 
tions of the Edit Patch modifier. 

Continuing on in Figure 5, we see 
that the models have been welded 
together, and the curvatures adjusted 
through use of the control handles 
(lower left). To add a belt to this char- 
acter, we need only to select a set of 
patches and extrude them, in much the 
same way as we would extrude a set of 
polygons. Following along in the fig- 
ure, we see that the patches are first 
selected, then extruded, and finally 
expanded using the Outline function 
of the tool. 


Noncontinuous Surfaces 


Oo ne subtle limitation for patch 
surfaces is that when a patch is 
subdivided, all the patches welded to it 
subdivide as well. This can be a prob- 
lem if the model you’re working with 
has areas of both high and low detail. 
This is the case particularly with 
humanoid characters, which can have 
areas of intricate detail around the face 
and hands, and areas of comparatively 
lower detail, such as in the arms, legs, 
and torso. Figure 6 shows an example 
of this. In this model, the head is fairly 
detailed while the rest of body is sim- 
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surprised? You shouldn't be. With the pop- 
ularity of new CD-R drives and the Inter- 
net, it happens all the time. And it costs 
you plenty. In fact, casual copying of CD 
games can reduce 7-10% of your revenues. 


That's why you need SafeDisc. It’s the best 
way to slow down piracy and prevent 
Casual copying from eroding your profits. 


It's fast. Protecting your rights doesn't 
take long and it doesn't interfere with 
game playability. 


It's easy. We have over 80 replicators 
licensed all over the world ready to work 
with you to protect your latest creation. 


It works. SAFEDISC-protected titles are 
being distributed by major publishers 
throughout North America, Europe and 
Asia — over 30 million disks last year 
alone. 


Take steps to protect your profits with 
SAFEDISC and burst the bubble of casual 
copiers once and for all. 


© 2000, Macrovision Corporation. SAFeDisc is a trademark of Macrovision Corporation and C-Dilla, Limited. 
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Even better that 
she got it for 
free! 


Call 1-800-900-4229 or visit our website 
at WWW.macrovision.com for more 
information. 


MAGROVISION 


Protecting your image 


1341 Orleans Drive 
Sunnyvale, CA 94089 
Phone: +1 (408) 743-8600 
Fax: +1 (408) 743-8610 
Web: www.macrovision.com 


see us at the Game Developer Conference, Booth #1142 


ARTIST’S VIEW 





ae 
oJ 


Me ake Ratna ae 
" le 
TY 


= 


sient einen ee abelian dee ilendniaaenionenimienenioninneidnininiaionmenmnieeinideinianeiniaiameenimemineete ™ 





0 Subdivisions 


1 Subdivision 


3 Subdivisiofiee 


aue 


FIGURE 6. Keeping the head’s surface separate from the body’s has its advantages. 


plistic by comparison. As a result, 
when the model is subdivided, the 
head will increase in complexity much 
faster than the rest of the model. In 


order to avoid this, the head has been 
kept as a separate surface, not welded 
to the torso. At the point where the 
neck joins the torso, there will be a 





ack in February (“Pyro-Techniques: Playing with 
Fire,” Artist’s View), | discussed the advantages of 
prototyping in-game effects through the use of pro- 
cedural effects such as Maya’s Particle FX and 3D 
Studio Max’s Combustion plug-in. One of the downfalls of proce- 


dural routines is that they fail to 
capture the subtle variations in 
shape, color, and density that 
are characteristic of most forms 
of combustion. For this reason, 
artists often rely on footage of 
real-life conflagrations upon 
which to base their effects. The 
downside of this is that unless 
you are generating the footage 
yourself, you pretty much have 
to settle for whatever you can 
get your hands on from a third 
party. With procedural effects, 
the artist has the advantage of 
being able to prototype and tweak 


the look of the effect directly. This has two clear benefits. The 
first, obviously, is that the artist is able to customize the effect in 
accordance with his or her needs without relying on an external 
source. The second, more subtle benefit is that by using a proce- 
dural routine to prototype the in-game effect, the artist gains 





\ 





discontinuity, but this has been hid- 
den beneath the collar on the model. 
Furthermore, by keeping the surfaces 
separate, it is possible to implement 
object-swapping for equipment adjust- 
ment, level-of-detail (LOD) implemen- 
tation, or selective morph-target ani- 
mation. The control point lattice on 
the top left has been surfaced using 
the Surface Tools method. On the top 
right, the image is rendered with zero 
subdivisions, which is equivalent to a 
normal polygonal model. Continuing 
around the image in a clockwise direc- 
tion, the model has been subdivided 
with an increasing number of subdivi- 
sions, with the head object containing 
one and two subdivisions, while the 
body goes through three and four lev- 
els of subdivisions respectively. Note 
the high amount of complexity within 
the head with only one or two subdivi- 
sions. The polygonal complexity of the 
head is roughly 220 quad polygons, 
with the next two levels at 1,100 and 
2,400 quad polygons respectively. The 
high amount of detail is a characteris- 
tic of patch modeling and is by far the 
most impressive visual property of this 


experience working with a particle system interface. This experi- 
ence will enable the artist to contribute to the design and imple- 
mentation of the in-game particle system. 

As particle system technology continues to advance, more and 
better particle routines are becoming available for use in game 


development. One of the most 
recent particle system plug-ins 
is Digimation’s Phoenix for 3D 
Studio Max 3. Similar in execu- 
tion to the Combustion plug-in 
that ships with Max, Phoenix 
generates a volumetric effect at 
render time, capitalizing on 
Max’s native particle technolo- 
gy. As you can See in the image 
at left, Phoenix is capable of 
generating a wide variety of 
realistic effects, from chaotic 
fireballs and luminous volumet- 
ric plasma, to a single flame ona 
matchstick. The interface is 


straightforward and functional, and the plug-in ships with a wide 
variety of preset effects routines, covering most of those required 
in game development. The product is currently only available for 
3D Studio Max, for around $4oo. (For more information go to 
hitp://Wwww.cigimation.cem.) 
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surfacing technique, highlighting the 
artist’s ability to store massive 
amounts of information within the 
low-resolution mesh. 


The Mad Scientist at Work 


4 n Figure 7 we see another, more 
striking example of the scalability of 
an in-game character model generated 
using the Surface Tools technique. At 





the lowest resolution, the character 
comprises roughly 1,800 three-point 
polygons, with the next two levels of 
subdivision at 6,000 and 23,000 poly- 
gons respectively. Note again that the 
control point lattice for this character 
is extremely low-resolution when com- 
pared with the final high-resolution 
model, and that due to the patch sur- 
face technique, these variations in 
complexity can be achieved totally on- 
the-fly simply by ramping up or down 
the number of sub- 
divisions in the 
patch surfaces. 
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eling are significant 
enough to warrant 
a change of 
methodology for 
most RT3D applica- 
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even larger benefit is seen once the con- 
tent actually makes it into a 3D engine 
which has been optimized for rendering 
patches. The most basic advantage from 
a rendering standpoint is that the result- 
ing surface has a regular, consistent 
structure, optimal for use in the ultrafast 
tri-strip rendering methods. Additional- 
ly, since there is a relatively small 
amount of data compared with the final 
topology, time spent on data transfer 
and geometry transformation is mini- 
mized. As a result, in most applications, 
switching from polygons to patches can 
double the resulting frame rate. Cou- 
pled with the resolution-independent 
nature of the content creation process, 
the advantages in rendering speed and 
data manipulation should enable the 
patch surfacing technique to maintain a 
solid footing in the RT3D world. That is, 
until the next big surfacing technology 
breakthrough comes along. @ 
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™ f you’ve been working on any kind of game that takes advantage of 





a 3D graphics accelerator, you’re probably painfully aware of the 


rapid pace at which 3D hardware evolves. 










| using textures. Today of course, things are very different. 
On-board textures and texture state management are fully 
supported by the major graphics APIs, and most graphics 
| cards come with gobs of texture memory. We alsq have the 
benefit of the AGP bus — a rapid data path designed exclu- 
sively for use by graphics cards. More recently, CPU manu- 
facturers added specific instructions (3Dnow! and SIMD, 
for example) to pump out more vertex transformations and 


use fancier lighting and blending operations. 
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Advances such as these 
came about largely because 
graphics card manufacturers 
have attempted to meet the 
texture management and fill 
rate demands that games 
place upon the graphics API. 
Many of these advances were 
the result of porting features 
available on SGI worksta- 
tions over to PC graphics 
cards, where consumer 
graphics chips manufacturers 
bottom-fed off of the SGI- 
developed hardware features, 
in order of easiest feature to 
hardest. 

As we've scarfed up more 
and more CPU cycles 
attempting to out-Carmack 
each other, we’ve been exer- 
cising those graphics APIs, 
pumping more and more 
textures and polygons 
through them, forcing the 
CPU to do more of the work. If your 
game isn’t doing its own transforms 
and lighting operations (T&L), it’s like- 
ly that the API driver is doing the setup 
and letting the CPU crunch those 
numbers. 

Fortunately, we recently entered a 
new evolutionary phase in which T&L 
can be performed on 3D objects by a 
dedicated graphics geometry processor 
residing on the graphics card. A num- 
| ber of such graphics cards already exist, 
| and more are coming out every quar- 
ter. Nvidia made the biggest splash 
with its GeForce 256 chip, which came 
out last fall and can be found on Crea- 
tive Labs’ 3D Blaster Annihilator, 
LeadTek’s WinFast GeForce 256, and 
Elsa’s Erazor X boards. S3’s Savage 2000 
chip, found on the Diamond Viper II 
board, also provides hardware T&L 
capabilities. And of course 3Dlabs has 
supported geometry acceleration for a 
while (no matter what Nvidia claims 
about being first), although 3Dlabs’ 
cards (including the Oxygen GVX1) 
have been targeted primarily at the 
professional market. You can expect 
that the rest of the major players will 
be shipping (or at least announcing) 
T&L boards by the end of the year. 

So we stand at the cusp of a new age 
of game graphics. Think about it: no 
longer do we have to perform multiple 
floating-point calculations on a vertex 
before sending it off to the API to be 
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FIGURE 1. The tree — gobs of textured, lit polygons ren- 
dered in real-time. 





rendered. Instead, you simply hand off 
the vertices to a graphics card and this 
work is done for you, allowing your 
CPU cycles to be spent on something 
else. Performing T&L calculations in 
hardware lets you make more complex 
3D models and scenes, enabling those 
freed-up CPU cycles to be used on 
other tasks (such as better Al). 

To answer naysayers who complain 
about the visual quality of scenes gen- 
erated by hardware T&L boards (or 
more particularly, by the lighting cal- 
culations performed by OpenGL and 
Direct3D), I concede the fact that cod- 
ing your own lighting routines can 
provide a distinctly better look and 
offer more flexibility than the stock 
lighting calculations provided by most 
graphics APIs. Perhaps that’s why hard- 
ware-accelerated T&L hasn’t been on 
the graphics card feature wish list of 
many game developers thus far. But 
taken as a whole, hardware-accelerated 
T&L is great because it means develop- 
ers can spend less time on the render- 
ing pipeline portion of their games. 

Talking about hardware T&L acceler- 
ation today is a bit like talking about 
how big a car’s engine is when you can 
only drive it in a parking lot. What you 
really need is a wide open space to rev 
up the engine and run that sucker flat 
out. Unfortunately, there aren’t yet any 
games that really stress the T&L 
engines. Nobody has designed a game 


with 20,000 to 50,000 polygons 
per frame simply because it 
would choke the non-T&L 
boards out there right now. 
Since we’re already choking the 
CPU with our T&L calculations, 
we’re left with little room to 
add more tasks when we 
already hog the machine. 
Hardware T&L enables us to 
load up the visual details of a 
scene while offloading a lot of 

_ the calculations involved onto 
the graphics geometry proces- 
sor. While there’s not much to 
actually using hardware T&L in 
your application (you just let 
the graphics API do the T&L), 
this article explains how to fig- 
ure out if T&L is available 
through Direct3D (which has 
the only “standard” way of 
reporting if hardware T&L is 
available), and explores cubic 
environment mapping, a new 
feature that most hardware manufac- 
turers have included with their T&L 
engines that simplifies the task of 
reflecting the environment around an 
object. 


Leveraging Hardware T&L in Games 


wa writing this article, I tested 
an Nvidia GeForce 256-—based 
card, which came with some demos. 
One of the more interesting demon- 
stration applications generates a tree 
procedurally using settings for the 
number of branches, leaves, and so on, 
which is lit by eight fireflies (simulated 
by eight colored positional light 
sources). You can adjust the demo set- 
tings to make the tree as bushy as 
you'd like, so I cranked up the level of 
detail (LOD) to see what would happen 
(Figure 1). At “normal” LOD settings 
the tree was still quite bushy, looked 
good, and ran at a reasonable speed. 
But at the highest LOD setting, my 
450MHz Pentium III workstation 
slowed down to about one frame per 
second. The reason for this can be seen 
in Figure 2 where you can see the high- 
LOD scene in wireframe mode. Notice 
the incredible amount of detail in that 
scene. They say a picture is worth a 
thousand words, and in this case it’s 
worth literally tens of thousands of 
extra triangles and quads. 
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You might wonder why I 
mention a 1FPS scene. Just 
look at the incredible detail 
in the scene shown in Figure 
2. This is far beyond anything 
we’d consider putting in 
game scenes previously, and 
without hardware T&L, it 
wouldn’t even be rendering 
that fast. But I assure you that 
frame rates for scenes such as 
this will quickly escalate. 
(Remember when we were all 
trying to figure out how to 
use texture mapping just a 
few short years ago? That 
problem was solved by the 
AGP bus and gobs of video 
RAM, and likewise I expect 
that today’s T&L challenge 
will not be around for long.) 

Taking advantage of hard- 
ware T&L means that you 
may have to change the way 


oh 


| you do things. Above all, you 


have to let go of the idea that you can 
code T&L routines that perform faster 
than the same solution performed in 
hardware. To make sure you get T&L 
acceleration, two requirements must be 
met. First, you have to let the graphics 
API do the hardware transformation 
and lighting calculations for you, even 
if your engine already does them. (Yes, 
I know you finally got your quaternion 
code working, but it’s time to move on 
to better things.) Second, you must ver- 
ify that you have hardware T&L and 
then you need to enable it in the 
graphics API. If you’re doing your own 
lighting or transforms (but not both), 
then you'll get some benefit from using 
hardware T&L. Thus, games such as 
UNREAL that do their own T&L won't 
see any benefit from hardware T&L 
accelerators. Games such aS QUAKE 3: 
ARENA that do their own lighting calcu- 
lations but let the graphics API do 
transformations for them will get some 
benefits from hardware T&L. 

Today, only the two major graphics 
APIs, Direct3D and OpenGL, support 
hardware T&L. You must be using one 
of these two APIs in order to enable 
hardware T&L. I suspect that if 3dfx 
continues to push Glide, we’ll see a 
T&L card and Glide driver from 3dfx in 
the near future. For now however, it’s 
strictly an OpenGL and Direct3D show 
if you want hardware T&L acceleration. 

For Direct3D to take advantage of 3D 
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of the re 


URE 2. The tree in wireframe illustrates the complexity 


ndering job. 





accelerators that support transforma- 
tion and lighting operations in hard- 
ware, check for the D3DDEVCAPS_HWTRANS- 
FORMANDLIGHT capability flag during the 
enumeration of devices. This flag is 
located within the dwievCaps member of 
the associated D3DDEVICEDESC7 structure 
and is returned when you call the 
IDirect3D7: :EnumDevices method. Alter- 
nately, you can check the GUID of the 
device being enumerated — T&L 
devices will be identified with 
IID_IDirect3DtnLHalDevice. (Previously, 
we’d look for IID_IDirect3DHALDevice and 
stop there.) Note that on a T&L-sup- 
ported card you'll find two hardware 
devices — the regular hardware HAL 
and the hardware T&L HAL, even 
though they may be the same device. 
(This is done for backwards compatibil- 
ity reasons.) 

To make sure you get T&L hardware 
acceleration in your game under 
Direct3D, you’ll need to add a prefer- 
ence in your code for the T&L device 
over the regular HAL device. Remember 
you're talking to some third-party dri- 
ver code here, so just because the card 
is in the machine doesn’t mean it’s 
automatically turned on. There seems 
to be a preference among the bleeding- 
edge chip makers towards 32-bit mode, 
so it might turn out that the new T&L 
interface only works on 32-bit color 
depths, while the legacy non-T&L 
interface is kept around for any 16-bit 





stuff. Remember that your 
mileage may vary depending 
on the graphics card and dri- 
ver combination your game 
will use. 

Using T&L hardware under 
OpenGL is a little different. 
Although the latest version 
of the OpenGL specification 
(version 1.2) doesn’t directly 
mention support for hard- 
ware T&L, it doesn’t really 
need to. With OpenGL, you 
just ask for a pixel format 
and you get “yes/no” infor- 
mation from the API about 
the availability of graphics 
acceleration. Since it is basi- 
cally “yes” or “no” if you 
have hardware acceleration, 
and since in most cases folks 
let the API do their T&L (or 
perhaps just the transforms), 
you'll automatically benefit 
from code that was written 
before hardware T&L. By simply 
selecting the hardware-accelerated dri- 
ver interface and letting the API do 
the T&L (or just transform or light- 
ing), your program will automatically 
benefit. Gee, what a great API. 

This is the spot in the article where | 
would have liked to insert a big chunk 
of code that you could cut and paste 
into your game and modify as neces- 
sary to get the best possible T&L accel- 
eration. But hey, if you let the API do 
your T&L for you, then the code is 
exactly like you’d have written it if 
you weren’t planning to implement 
T&L acceleration. In other words, 
implementing this support doesn’t 
have to be difficult. The only tricky 
part is enumerating and selecting the 
T&L driver under Direct3D, since the 
T&L driver has been given a new GUID. 


Drawbacks to Hardware T&L 


s there a downside to using hardware 

T&L? There can be. First, let me clear 
up one common misconception. Re- 
cently, people testing the GeForce 256 
(one of the first consumer chips to sup- 
port hardware T&L) have claimed that 
they cannot see much, if any, perfor- 
mance difference between using T&L 
acceleration and not using it. Some of 
this might be due to the fact that some 
of the tests being performed aren’t real- 
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ly designed to assess T&L. After all, if 
the difference between a T&L driver 
and a non-T&L driver is merely some 
capability bits, but OpenGL programs 
(which have always had built-in matrix 
memory and math routines) still let the 
hardware handle T&L, is it reasonable 
to assume that T&L won’t occur in 
hardware if you’re running on a T&L 
card? (Remember that the program 
doesn’t have to change — it still passes 
the same matrix information and ver- 
tex list to the API.) To truly see the dif- 
ference this new generation of hard- 
ware provides, we need new tests to 
stress the T&L capabilities of the chip 
— tests that churn through huge num- 
bers of polygons per frame. You should 
be able to double or triple the number 
of polygons in a game compared with 
the numbers we’re used to using, and 
see little performance impact on a 

T&L accelerator. Such tests should be 
available in short order — I’m creating 
some of these tests, and I’ll post the 
results on my web site when they’re fin- 
ished. (If you have any suggestions or 
have done your own testing and would 
like to share the results, feel free to con- 
tact me.) 

Aside from these misunderstood test- 
ing issues, there can be genuine 
instances when implementing hard- 
ware T&L will hurt application perfor- 
mance. Recall that computing T&L in 
hardware means that your game must 
give the card all of a scene’s vertex 
data, as well as the lighting and transla- 
tion parameters. This is similar in con- 
cept to sending texture data to the tex- 
ture memory on the graphics card. It’s 
faster to have the texture memory 
reside on the graphics card, but it’s 
slower if you need to change or access 


GAME DEVELOPER APRIL 2000 


Vertex-rich tree in wireframe mode, showing its high poly- 


gon density. 


that data. But there may be occasions 
when you need to get the results of a 
T&L calculation back over the AGP bus 
and back into system memory so you 
can use the results. For instance, your 
game might require the location of 
some object in worldspace, perhaps in 
order to calculate whether two objects 
collided. If you’re using hardware T&L, 
it can be computationally expensive to 
request this information from the API 
since the API might be doing some- 
thing else (caching data to optimize 
calculations, for example). To retrieve 
information from the hardware, the 
API must flush all pending calculations 
to update its state before it can return 
that information. As such, repeatedly 
requesting data during a rendering 
cycle can trash the caching/optimiza- 
tion scheme. I brought this issue up at 
a 3D graphics roundtable discussion at 
the 1999 Game Developers Confer- 
ence, but the issue hasn’t been resolved 
yet by the APIs. (Again, if you have any 
ideas, pass them along.) 

Some method is needed to mark cer- 
tain state transformations as “volatile,” 
so the data associated with these trans- 
formations doesn’t get stuffed into the 
bowels of the graphics CPU. Caching 
the data in the driver is one way to 
maintain access to it, but you’d get no 
benefit from hardware T&L in this case 
if you requested the data frequently. 
Currently, the only solution to this 
problem is to let the graphics API take 
care of the T&L, and for you to main- 
tain your own copy of the translations 
(so don’t throw away all your matrix 
and vector code just yet) and perform 
your collision detection (and so on) 
using a local copy of the transforma- 
tion data. 





Yes, this “solution” is ugly. After all, 
if I want the API to handle T&L, | 
want to unload all my T&L code, not 
keep a duplicate around. All I can say 
to rebut this is that the kinks with this 
technology are still being worked out. 
(It reminds me of the time when 
someone first explained to me how to 
do multi-pass texture effects. My 
response was, “You want me to render 
the whole scene three times every 
frame? You’re kidding!” Now APIs 
have taken over that chore for the 
most part, and we’re trying to figure 
out the best way to let the graphics 
chip handle some of the calculations 
while still letting us peek at the results 
as necessary.) 


Cc: environment mapping is a 
feature supported by the latest 


revisions of OpenGL and Direct3D 
that has debuted as a hardware-sup- 
ported feature in the latest crop of 
hardware accelerators. An environ- 
ment map is essentially a texture map 
of a scene viewed from one spot. In 
the past, such environment maps were 
generated for a scene or taken with a 
360-degree camera or one with a fish- 
eye lens. This usually gave you a pretty 
distorted texture, but since the texture 
was going to wrap around some shiny 
object for the purpose of creating a 
reflection, inaccurate environment 
maps typically sufficed (no one com- 
plained much except artists). Now that 
new graphics hardware can generate 
and process cubic environment maps, 
scene-accurate, real-time reflections 
are a reality. 
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The advantage of the cubic environ- 
ment mapping technique is that when 
compared with traditional spherical 
texture map methods, it’s easier to 
generate and use the reflected images. 
As such, cubic environment maps let 
you make more complex scenes, ren- 
der a scene multiple times, and create 
dynamic, realistic reflections of it. 
Another plus is that you don’t get a 
singularity at the poles, which is the 
case with spherical texture maps. You 
can generate the environment textures 
at run time and update the environ- 
ment maps, updating the textures 
every frame to keep the reflected tex- 
ture map accurate to the current scene. 
Even if your environment map is stat- 
ic, it’s still easier to generate the envi- 
ronment map by rendering the actual 


_ | reflected scene and saving it. 


There are two steps to implementing 
cubic environment mapping. First, 
generate the texture map of the envi- 
ronment surrounding the object on 
which the map will be applied. 
Direct3D uses a special texture layout 
scheme just for cubic environment 
maps that’s based upon an unfolded 
cube with ordered faces — hence the 
“cubic” term. OpenGL’s solution is 
similar, although it doesn’t order the 
cube faces. The second step is simply to 
load up the faces of the cube by render- 
ing the scene from the center of the 
cube for each cube face and voila, you 
have your cubic environment map. 
The conceptual layout of the textures 
can be seen in Figure 3. 

To create a texture to use as a cubic 
environment map using DirectX 7, you 
call the IDirectDraw7: :CreateSurface 
method. A cubic map is created as a 
series of attached surfaces (or “complex 
surfaces,” in Direct3D parlance). There 
are three things to keep in mind when 
creating a cubic environment map: 
You cannot create the cube’s surfaces 
individually, the dimensions you speci- 
fy are the dimensions of an individual 
side, and each side of the cube must be 
both square and a power-of-two length 
(32x32, or 64x64, or 128x128 pixels, 
and so on). Typically you render this 
environment map onto a small reflec- 
tive object so your cube dimensions 
can be small as well. That’s good news. 
Because this is a multi-pass rendering 
technique, the cubic texture should 
probably be kept as small as possible to 
maintain good performance. To gener- 
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LISTING 


. Cubic environment map code under Direct3D. This shows some 





Wig-ta e713) age 7 or better) code that will allocate a cubic environment map. 


DDSURFACEDESC2 ddsd; 


ZeroMemory((LPVOID)&ddsd, sizeof (DDSURFACEDESC2)) ; 


ddsd.dwSize = sizeof (DDSURFACEDESC2) ; 


ddsd. dwFlags = = DDSD_ CAPS Q posb WIDTH 1 oso. 0HEIGAT | DDSD_ PXELFORMAT; 


ddsd. ec vai = DDSCAPS. TEXTURE; a 


// Assume pDD7 isa pointer to an IDirectDraw7 interface. 


// Set the piel format. to a a valid es ture f neler 






































// We set the DDSCAPS, _SDDEVICE bit € waly | ify we 2 want to use the - environme 
// target. If you’re ‘going to just load textures, you. don’ t need this flag se 
ddsd.ddsCaps.dwCaps = DDSCAPS_COMPLEX | DDSCAPS_ 3DDEVICE | DDSCAPS_ TEXTURE; 


// Here’s where we state that it’s a cubic environment map and that ie sa all 6 faces 


// created at once. 


ddsd.ddsCaps.dwCaps2 = DDSCAPS2_CUBEMAP | DDSCAPS2_CUBEMAP_ALLFACES; 


LPDIRECTDRAWSURFACE7 pddsCubeMap ; 


// And here’s where we create the cube map complex surface. 
if( FAILED( pDD7->CreateSurface( &ddsd, pddsCubeMap, NULL ) ) ) 


{ 
// something bad happened. 


ate the optimal map, I suggest you ren- 
der your scene in a window and make 
the window smaller and smaller until 
you Start to lose fidelity. Then round 
up the dimensions of the texture to the 
next power of two. 

If your scene requires Z-buffering, 
you can create a separate Z-buffer and 
attach it to the cubic environment 
map. Alternately, you can detach the Z- 
buffer from your back buffer (assuming 
you created one) and attach it to the 
cube map before you render, then re- 
attach it when you’re rendering the 
scene “for real.” 

Rendering the cubic environment 
map to an object can get nasty. First, 
you allocate the environment map 
texture memory for the current scene, 
as shown in Listing 1. Assuming that 
we can call some “render” method on 
our scene to render all objects in their 
correct positions in worldspace, we 
just need to set the viewpoint to the 





FIGURE 3. Conceptual layout of the 
cubic environment map. 


center of the cubic environment map 
and render the scene into the map. 
You do this for each of the six sides of 
the cube. This gives us six additional 
renderings of our scene for each cubic- 
environment-mapped object within 
the scene. So far, so good. But things 
can get tricky when you have multiple 
cube maps that are within sight of 
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each other. You run into the problem 
of accurately generating the reflec- 
tions of the reflections, which must be 
repeated n times (where n is the num- 
ber of times you want the reflected 
scene reflected in your environment 
map). Acommon solution to this 
problem is to use the previous frame’s 
rendering in the reflection repeatedly 
for each frame, as long as you don’t 
mind your reflections being off a 
frame in the reflections. It’s not a per- 
fect solution, but it still looks good 
most of the time. (Yet I doubt we'll see 
many games with multiple real-time 
cubic-environment-mapped objects 
anytime soon.) 

Listing 2 illustrates the process for 
rendering a cubic environment map 


FIGURE 4. The actual cubic environ- 
ment map for the scene. 





in pseudocode. This code 
describes the process within 
Direct3D; OpenGL supports 
cube mapping through an 
extension mechanism. (On my 
GeForce card it’s the EXT_tex- 
ture_cube_map extension.) 

After you've reset the view- 
port and all matrices (in step 7), 
then you can render your scene 
again using the environment 
map we just created. The result 
is a texture map that looks like 
Figure 4. 

If you are wondering how 
the texture coordinates are 
used (since the cube texture 
maps are treated as a 3D texture), let 
me explain briefly. The vertex texture 
coordinates are treated like a direc- 
tional vector with an origin at the 
center of the cube. The largest coordi- 
nate axis is the one that selects the 
cube face. The remaining minor coor- 
dinate axes are divided by the larger, 
and these two values are treated as the 
2D U and V coordinates to the cube 
face. From that point onward, the 
cubic environment map is treated just 
like a regular 2D texture map. 

While the effects created by cubic 
environment maps are pretty neat, it 
does affect rendering speed. Without 
the benefit of hardware acceleration, a 


LISTING 2. Process of generating and rendering a cubic environment map in 


pseudocode. 





1. Prior to rendering the scene, render the cube map. 
2. If the cube map dimensions are small, enable antialiasing for the cube rendering. 


3. Set the viewport to the cube dimensions. 


4. Set the perspective matrix to a 90-degree field of view for both the X and Y axes. 


5. For all six faces of the cube map: 


a. Set the render target to the current face. 
b. Optionally swap the Z-buffer to this map. 
c. Set the viewpoint LOOK and UP vectors as follows for the particular pass: 


Cube face LOOK Direction UP Direction 
positive X positive Y 

1 negative X positive Y 

2 positive Y negative Z 

3 negative Y positive Z 

4 positive Z positive Y 

5 negative Z positive Y 


e. Set the modelview matrix according to LOOK and UP vectors centered at 


cube center. 
f. Begin scene. 


g. Render everything in the scene but this object. 


h. End scene. 
6. Restore render target. 
7. Reset viewport and all matrices. 
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FIGURE 5. The scene with a reflective sphere 
incorporating the cube map. 





typical scene is rendered about two to 
ten times slower than without an 
environment-mapped object — hence 
the requirement for a T&L graphics 
card (which usually includes cubic 
environment mapping in hardware). 
But you do get spectacular effects out 
of it, as shown in Figure 5S. This image 
shows a sphere that was environment- 
mapped with the texture from Figure 
4. A more interesting example is 
shown in Figure 6, where there is sub- 
tle interaction between the environ- 
ment and the model’s hair: as the 
woman moves her head, the high- 
lights on her hair change to reflect the 
environment. 

While cubic environment mapping 
is a useful feature, I’d rather see it 
pushed further into the API. Right now 
it’s got the feel of a hack, so hopefully 
as the API folks get more feedback 
they’ll refine the API to make the setup 
and rendering process less onerous. 
While it’s nice to have non-90-degree 
viewpoints, or to create the faces sepa- 
rately, 99 percent of the time you use 
the same defaults, so a lot of setup 
could be avoided by providing an easi- 
er-to-use set of default interfaces, there- 
by putting less of a setup burden on 
the programmer. 


2001: A New Game Odyssey 


Ww" about to be handed a big 
dividend in the form of low- 
cost T&L calculations, and like it or 
not, if you’re coming out with a 3D 
game for Christmas 2001, you ought to 
incorporate hardware T&L into your 


title if you want-your game to be com- 
mercially competitive. 
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This is an issue that I think will have 
a revolutionary effect on the games 
market, but it will take a while for 
everyone to get comfortable with how 
best to incorporate T&L into the pro- 
gramming. The upside is that in the 
next few years we can expect to see 
some incredibly detailed games with 


spectacular environments. We can use 
this functionality to incorporate more 
complex models, better Al, or some 
other feature that would previously 
have placed too much strain on an 
already-burdened CPU. 

For the time being, it’s up to us to 
test out these new hardware features 


FIGURE 6.Example showing the subtle interaction between the environment 
lighting and the model. 





and do our best to give feedback to 
the chip manufacturers and API archi- 
tects. In the meantime, we must help 
them in order for them to help us add 
complexity to our content. Test out 
one of the new T&L cards and see how 
you can get more content into your 
game. 
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/ hen I was a kid, I used to 
leave my room — or wherever I 
went, really — a total mess. I’d 

~ like to be able to say that I’ve 
changed and am a really tidy and 
responsible person now, but that would 
be a stretch. Iam, however, going to clean 
up the awful mess [| left us in after the last 
issue, where we had a bunch of equations, a 
whole lot of terms, and not much of a clue 
about what to do to get a ponytail simula- 
tor out the other end. 


When We Last Left Our Heroes... 


here’s no escaping the fact that you need to read last 

month’s part one article (“How to Simulate a Ponytail,” 
March 2000) in order to read this part two. I can’t review it in 
any meaningful way, so I’m just going to set up our initial 
conditions from the end of last month’s article and move on. 
Figure 1 shows the bodies and notation we’re using, and 
Table 1 contains the equations we ended up with. 

In part one, we decided to do the derivation for two con- 
strained bodies first, to keep things manageable, and then 
later generalize it to the longer chain of bodies that make up 
the ponytail. At the end of part one, we had written out equa- 
tions for the linear and angular accelerations of our simple 
two-body system when they were affected by the constraint 
force, f., as you can see in Equations 1 and 2. We also deter- 
mined that Equation 3 was going to be the constraint equa- 
tion we would attempt to satisfy at all times during the simu- 
lation using the constraint force. If we could satisfy Equation 





Chris Hecker (checker@d6.com) is the Editor-at-Large of Game 
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3, and our simulation started with the position and velocity 
constraints satisfied, we’d have a constrained rigid body sim- 
ulator. Finally, I said the end product of all the plugging and 
chugging with equations would be a linear system of equa- 
tions looking like Equation 4: Af. = b. We'd solve this equa- 
tion for the force of constraint, and then apply it back to the 
objects to stick them together. 


Plug ‘n Chug 


WW: originally derived Equation 3 because we needed 
the constraint equation to be in terms of accelera- 
tions rather than positions or velocities. Now that we’ve got 
it in acceleration space, we can enforce it with f., since we 
know forces can directly affect accelerations. Still, it’s not 
immediately obvious how to get our f. into Equation 3, 
where it can do some good. 

Equation 3 is too abstract for our needs. It simply says the 
acceleration of the two constraint endpoints must be equal. 
It makes sense that the force of constraint, f., can affect the 
accelerations of the endpoints by pushing and pulling on 
the bodies, but how do we show this mathematically? First, 
we need to express the endpoint accelerations in terms of 
the body’s linear and angular accelerations, which we know 
are directly affected by f. via Equations 1 and 2. 

Remember from part one (or from my original physics 
articles from Game Developer, referenced at the end of this 
article) that the equation for the acceleration of a point fixed 
on a rigid body — say, Body A — looks like this: 

f, =k, +2, X71, +O, ® (o, x e,| Eq. 5 
Equation 5 contains the second derivative of R, (the vector 
to the center of mass of the body) and a, (the angular accel- 
eration of the body). These quantities are definitely affected 
by f. as shown in Equations 1 and 2. 





Py —p, =0 


FIGURE 1. 


Bodies and notation from 
last month’s article. 
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If we substitute Equation 5 and its counterpart for Body B 
into Equation 3, we get a very long equation. Then, if we 
substitute Equations 1 and 2 and their counterparts for Body 
B into the very long equation, we get an extremely long equa- 
tion. At that point, our extremely long equation is in terms 
of our only unknown, f., and we can munge it around until 
we get something that looks like Equation 4. We could do 
this, but we’d probably go insane trying to keep all the terms 
straight with all their subscripts and whatnot, and I know I’d 
go insane trying to type all the intermediate stages into the 
evil Equation Editor. 

We'll take a step back, and just work with Equation 5 for a 
little while. We can move ahead under the assumption that 
anything we do to Equation 5, we can do to its Body B part- 
ner. If we can simplify Equation 5 before substituting it into 
Equation 3, then we can do the same for the B version and 
we'll stay sane. 


One Term at a Time 


ook at the first term on the right hand side of Equation 
S, the acceleration of R,. Equation 1 just drops into 
Equation 5S in place of this term, and we get Equation 6: 
Da =Mj fF. +My Fu, +O, Xt, +O, X(@, XT, ) Ha, 6 
This is already starting to get messy. We can simplify a bit 
by introducing a new term, b,. We'll use b, to hold all of the 
“known” terms in the equation. The known terms are those 
that contain quantities whose values we know how to calcu- 
late at any given time. So, as we discussed in part one, the 
external forces are all known at a given timestep, meaning 
we can stuff the F,,, term into b,. Also, the last term in Equa- 
tion 6 is known because it only contains angular velocities 
and the position vector, r,, both of which are known at any 
timestep since they were integrated forward from a previous 


1. Review equations from last month’s article. 
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timestep. So, our b, looks like this so far: 

b, = Mj’ Fry + @, X (o, x fi) Eq. 7 
And, our simplified Equation 6 looks like this: 

Pr =Myf.+a, x1, +d, Eq. 8 

The substitution of Equation 2 for @, is more complicat- 
ed. First, the @, is inside a cross product, which means the 
entire right-hand side of Equation 2 is going to have to go 
into the first term of that cross product. This makes perfect 
sense mathematically: a, is a vector, and so the right-hand 
side of Equation 2 is a vector as well — it’s simply com- 
posed of a bunch of other vectors. It’s a big mess symboli- 
cally, though, because replacing the single symbol on the 
left-hand side of Equation 2 with the multi-term expres- 
sion on the right-hand side makes the cross product pretty 
much unreadable, and we have to use parentheses to keep 
everything straight. 

We'll concentrate solely on the a, term in Equation 8 and 
ignore the other terms for a moment. We substitute in Equa- 
tion 2 and use the fact that the cross product distributes 
across addition and subtraction: 


é, Kh, = a(n, 8 Also Te ing [Ey -|I,'(@, wl, Viney 


Eq, 2 

Now, before dropping Equation 9 back into Equation 8, 
let’s try to stick a bunch of it into b, to get it out of the way. 
The first term on the right-hand side of Equation 9 contains 
f., So we need to keep it around, but the other two terms are 
both known, since they contain only external torques, 
velocities, momenta, and positions. Away into b, they go, 
leaving us with: 


b, = Mi Fea + @q (4 X14) +[L5) te — 1G (@4 XL,)] X14 


Eq. 10 
I “un-distributed” the cross product of the two known terms 
in Equation 9 when writing Equation 10 to make it a bit 
shorter. 
Our equation for the constraint endpoint acceleration 
now looks like this: 


By = MAF. +[Ti'(ta x fe) Xt + a Eq. 11 


As you can see, it’s much simpler than it could have been, 
but we’ve still got some work to do. 


A Breather 


et’s take a break and assess our situation. We have 

Equation 11, which is an equation for the acceleration 
of Body A’s constraint endpoint in terms of the known 
quantities (most of which are tucked away in b,), and the 
unknown constraint force, f.. That is, at any given time we 
can calculate the value of the b, vector, and plug it into 
Equation 11. We can also calculate all of the other known 
terms on the right hand side of Equation 11, such as the 
mass, inertia tensor, and constraint vector, r,. The excep- 
tion is f.; we don’t know it in advance. In fact, our whole 
goal is to solve for f. so we can plug it back into Equations 
1 and 2 to find the acceleration of the bodies under 
constraint. 
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Since f. is our unknown, we need to get it in a better posi- 
tion to be manipulated. The first term on the right-hand 
side of Equation 11 is pretty reasonable, since it’s just a 
matrix times f.. This term looks a bit like Equation 4, so we 
know we’re getting close. However, f. is stuck inside two 
cross products in the second term, which is a far cry from 
Equation 4. 


Cross Products 


a ow do we get f. out of the cross products? Cross prod- 
ucts are notoriously hard to manipulate, unless you 
have the following definitions in your bag of tricks: 


axb=-bxa Hd. 12 
O -a; a,|\D, 

axb=ab=\a, O- -a,|b, 
ra, OLS Eq. 13 


Equation 12 is the familiar rule stating that when you 
reverse the cross product terms, the resulting vector is negat- 
ed. This is what you see when you accidentally compute a 
triangle’s normal by crossing the edges in the wrong direc- 
tion — you get the inverted normal. 

Equation 13 defines the “tilde operator,” which, when 
applied to a vector, creates the matrix shown in the equa- 
tion. It just so happens that this tilde-matrix of vector a — 
also called the “skew symmetric matrix of a” — times vector 
b gives the same resulting vector as taking the cross product 
of a and b (multiply the matrix-vector product on a piece of 
paper to double-check it for yourself). This is a great trick, 
because it turns a cross product into a matrix-vector product, 
which we know how to manipulate. 

Now we can pound on our cross product term. First, let’s 
get f. on the right side of the expression by applying Equa- 
tion 12: 


a(t x f.)| Kr, af, & inl x f.)] 


Next, we “tilde-ize” the outer cross product: 


—T, x bigi? xT, ) = la ts x fe) 


Notice how the outer brackets aren’t needed anymore, 
because now we just have a matrix multiply of the tilde’d r, 
and the inverse inertia tensor. Finally, let’s tilde-ize the 
inner cross product: 


we il & GX 
Tt, (r, x f) = yl tal 
Our result is simply three matrices times our unknown vec- 


tor. Let’s put this result back into Equation 11 and group the 
terms to isolate f-: 


Ps - M; f. if ha tad + b, 
Pi - [M ;" = ver If + b, 
pn, =A,f.+b 

Pa al. * A Eq. 14 


Now we’re in business. I’ve renamed the grouped matrices 
“A,” to highlight the structure of the equations. We have a 
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known matrix, A,, and a known vector, b,, and our 
unknown f.. We’re not quite at Equation 4, but we're 
extremely close. We only need to get rid of the p, accelera- 
tion term, and that’s our cue to substitute back into 
Equation 3. 


f you look at all the work we did to get from Equation 5 
to Equation 14, you’ll see that very little of it depended 
on whether we were talking about Body A or Body B. There’s 

really just one difference between the bodies, and we’ve 
already mentioned it: f. is positive for Body A, but negative 
for Body B. This means we can simply rewrite all the equa- 
tions with B subscripts, and if we’re careful to substitute in 
~f. wherever f. shows up, we’ll have valid equations for Body 
B. We don’t have to rederive everything. 

We can actually just write the Equation 14 for Body B by 
inspection: 


Pa ~ A,(-f-) +b, =—-A,;f. +d; 

Eq. iS 
The A, matrix and the b, vector are calculated exactly as 
shown above for Body A, and we simply negate the f. term. 
Equation 3 tells us we can subtract Equation 15 from Equa- 
tion 14 to get 0, assuming we’re enforcing our constraint 
properly. Let’s write the subtraction, taking care to get our 
signs right: 


Pa - Pp =A,f. +b, +Azgf. —D, =0 
Finally, let’s group our terms to match Equation 3: 


[Ay © A, If. = —b, +b, 
Eq. 16 
That’s it. We have a linear system matching Equation 4, 
where A=A, +A, and b=-b, + b,. A and b are known, and 
f.is unknown, meaning that at any given time, we can con- 
struct Equation 16 for the two rigid bodies, and then solve it 
for f. to find the constraint force that will hold the bodies 
together. 


The Simulation Algorithm 


Re ow we’re ready to outline the overall simulation algo- 
rithm for two rigid bodies with one constraint: 


1, Compute the extemal forces: P 4, Tra F per Tey 
2. Compute the A matrix and the b vector. 

3. Solve the linear system for f.. 

4. Apply f. and the external forces to the objects. 
5. Integrate forward. 


After step three, f. is a known force, just like the external 
forces. The forces can now all be applied to the bodies in the 
usual way. Remember, f. is applied at the tip of the con- 
straint vector, so it will induce torque on the objects as well 
as apply a force to the center of mass. Also remember that f, 
is applied negatively to Body B. 
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The Linear System 


Ss: how do we solve the Af, = b linear system? This is 
actually the easiest part of the algorithm in some 
sense, because there are so many different ways to do it. 
Solving linear systems on computers is the most studied 
area of numerical analysis, and there are hundreds of books 
about doing it right and lots of free source code. You could 
probably write your own Gaussian Elimination routine in 
a few lines of C, or you could download some fancy 
numerical linear algebra package if you’re so inclined. 

If you’re just interested in solving the 3x3 system in 
Equation 16, you could even use Cramer’s Rule or just 
solve the system by hand symbolically, but those tech- 
niques won’t scale to the larger systems that occur when 
we add bodies. When I wrote the sample application for 
this article, | downloaded a simple linear system solver 
from the web (http://www.netlib.org) and hacked it into 
my program. See the references for details on the sample 
application. 


Kinematic Control 


efore we generalize our derivation to multiple 
bodies, let’s talk about how kinematic control fits 
into our formulation. From last month, you’ll remember 
the head of the character is kinematically controlled, 
meaning its movements are already known from an 
animation. It’s easy to integrate animated bodies into our 
algorithm. 

First, we need to be able to generate values for the 
known position, velocity, and acceleration of the kinemati- 
cally controlled body at a given point in time. We can find 
the equations for these values from our animation system 
in most cases. The position equation is simplest — we have 
to have that around if we’re animating the body in the first 
place. The velocity and acceleration equations are attained 
by differentiating the equation for position. If we’re inter- 
polating keyframes, then the interpolation function will 
give us the velocity at a given time when we differentiate 
it. Another differentiation gives us the acceleration. For 
example, if we’re linearly interpolating positions between 
keyframes, the velocity will be constant and the accelera- 
tion will be zero. Linear interpolation is not continuous 
at the keyframes themselves because the direction changes 
sharply, so be careful about differentiating in those areas. 
If we’re linearly interpolating joint angle keyframes, our 
velocities and accelerations will be nonlinear, but still 
derivable from the equations. If we’re doing a more soph- 
isticated continuous spline interpolation, our derivatives 
will be even more complicated, but we should still 
be able to attain equations for the velocity and 
acceleration. 

Once we’ve gotten the linear and angular positions, 
velocities, and accelerations from our animation system, 
we use these known values everywhere they appear in our 
equations. Equations 1 and 2 for the kinematically con- 
trolled body become known values, rather than equations 
depending on the force of constraint. All of the animating 
body’s kinematic quantities are now known and end up in 
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the b vector. When we compute f., the computed force 
will make the dynamically controlled body obey the move- 
ment of the constraint due to the kinematically controlled 
body’s animation. We don’t apply the constraint force to 
the animating body because, well, it’s animated, not 
simulated. 


Multiple Constraints 


wo bodies does not a ponytail make. Do we have to re- 

derive everything when we want to do three bodies with 
two constraints in a chain, not to mention N bodies with 
N-1 constraints? Thankfully, the answer is no. The equa- 
tions for multiple bodies and constraints are very similar to 
those we’ve already derived, but we need to talk a bit more 
about the structure of the multi-constraint problem before 
we can extend them. 

The first thing to notice is that we have to solve for all of 
the constraint forces simultaneously. If I have a chain of 
three bodies, and I pull up on the top body, not only does 
the middle body have to feel the yank, but the bottom body 
does as well. If we didn’t solve simultaneously, the force of 
the pull would ripple down the chain in the order we solved 
the constraints, and the chain would separate. This is not 
the behavior we want. 

Because we need to solve 
simultaneously, all of the 
constraints need to be rep- 
resented in the equations 
we write. This forces us to 
develop some new nota- 
tion that will scale to mul- 
tiple constraints. Bodies 
can now have two con- 
straints attached to them, 
rather than just having one 
as in our two-body deriva- 
tion. It turns out that it 
makes the most sense to be 
“constraint-centric” in our 
notation, numbering the 
constraints and having 
them refer to the bodies 
rather than having the 
bodies refer to the 
constraints. 

Figure 2 shows this nota- 
tion. The constraints are 
numbered 1, 2, and 3; if we 
were being completely gen- 
eral we’d call them i - 1, i, 
andi+1. We're going to 
talk about the middle 
joint, number 2. We'll call 
the forces at each con- 
straint f.,, f->, and f.,. The 
constraints attach the two bodies on either side of the joint, 
and I’ve chosen the subscripts u and d to stand for the 
“upstairs” body and the “downstairs” body relative to the 
joint in the figure. So, the body between joints 1 and 2 is the 
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A multi-constraint system. 





upstairs body of joint 2, and the other body is the down- 
stairs body of joint 2. The constraint endpoint of the top 
body for joint 2 is denoted p,,, and the endpoint from the 
bottom body is p,,, and so on. The constraint endpoints and 
the r vectors are still attached to their respective bodies, but 
they’re numbered relative to the joints. Notice that the u- 
body of joint 2 is the d-body of joint 1. 

While I make no claims to the elegance of this notation, it 
will let us get the job done. 


General Acceleration Equations 





GS iven the new notation, we could rederive all of our 
equations for the new general constraint. We don’t 
have the space for that (and it’s almost identical to our pre- 
vious derivation), so we’re going to skip ahead and show the 
structure of the equations we end up with for joint 2. The 
accelerations of the two endpoints associated with joint 2 
look like this: 


Du, = Asyol c2 ~ Aju cl * b», BQ. 17 


Pra = —Arache2 + Acastcs + Pra Eq. 18 
A single joint is affected not only by its own constraint 
force, but also by the constraint forces on 
either side of it. This is because the body 
accelerations are modified by all the con- 
straint forces acting on them, and those 
body accelerations appear in the equation 
for the constraint. Put another way, the 
top body’s motion at joint 2 is dependent 
on what joint 1’s force is doing, in addi- 
tion to what joint 2’s force is doing. 

I haven’t described what the A matrices 
look like exactly, but they’ll be very simi- 
lar in composition to the A matrices we 
derived above, so we can just deal with 
them symbolically here. They’re subscript- 
ed to describe their function: A,,, is the 
matrix for joint 2’s upstairs body that mul- 
tiplies f.,. In English, A,,,, describes the 
acceleration effect f., has on joint 2’s 
upstairs endpoint. Put yet another way, 
A,,,; Maps the force from joint 1 to an 
acceleration at joint 2, through the body. 
To belabor the point a bit more, if you 
look at the expression that makes up A, _, 
(once you’ve derived it, of course!), you'll 
see that it converts f., to accelerations on 
the center of mass, and then maps those 
accelerations out to p,,.. 

Although I didn’t mention this way of 
thinking above, the original A, and A, 
matrices from the two-body derivation 
work the same way. The linear acceleration 
is transferred through the M~! term, and 
the angular acceleration is transferred through the cross 
product (or tilde matrix) and inertia tensor term. In A, and 
A, we're mapping the constraint force from the joint, down 
through the body, and back up to the same joint, but the 
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principle still applies. In Equations 17 and 18, A,,, and A, i 
are similar to A, and A,, since they map f., to acceleration 
back at joint 2. 

We’ve also adopted the convention of applying the con- 
straint force positively to the u-body and negatively to the 
d-body, which accounts for the negative signs in Equations 
17 and 18. 


The Multi-Constraint System 


f we subtract Equation 18 from Equation 17 and group 

terms, we get the constraint equation we must satisfy for 
joint 2: 

Agata t [ Asus * Ava Ifo — Agasfcs = —Day + Dra Eq. 19 
This equation has the three unknown vectors in it, but it’s 
only one vector equation. To solve a linear system, we need 
as many equations as we have unknowns. Where will we 
find the other equations? From the other constraints, 
naturally. 

Let’s assume for the moment that the system in Figure 2 
has four bodies and the three constraints shown. In other 
words, although they’re only hinted at in the figure, there is 
a body above joint 1 and a body below joint 3. These outly- 
ing bodies each has only one constraint (joint 1 for the 
upper body and joint 3 for the lower body, obviously), and 
they are the endpoints of the chain in this example. Given 
this system, the equation for joint 1 is: 


[Aut ua Aealha — Angohen = Py + Pra Eq. 20 
And the equation for joint 3 is: 
-A3,,2 c2 +t [Aju +r Kaze ifs - Day g 4 bs, Eq. Zt 


Notice that Equations 20 and 21 have only two constraint 
forces each in them, as opposed to the three forces in 
Equation 19. The equation for the end joints in a chain will 
have only two constraint forces because the extremal bodies 
don’t have a joint on their “far” side (or they wouldn’t be 
very extremal, now would they?). 

Now for a bit of matrix magic. Equation 20 contains f., 
and f.,, Equation 19 contains f,,, f.,, and f.,, and Equation 
21 contains f., and f.,. Each of these equations depends on 
one or more of the other ones. This is the mathematical 
expression of our statement above that the constraints must 
be solved simultaneously. We can construct a single large 
matrix equation that contains all of these equations by 
stacking them up, like so: 


Ava + Aaa —Avi> 0 f.4| |-Dy, + Prg 
-A, 4 Avie + Mog -A,33 f o| =|-b3,, + Pog 
0 -A,5 A,3 + Agza3l If-3] 23, + D3a 

Eq. 22 
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If you perform the matrix multiply in Equation 22, you 
can see you get the exact equations listed above. Further- 
more, Equation 22 is just another Af. = b linear system, 
where A now stands for the compound matrix in Equation 
22, and f. and b (with no numbered subscripts) stand for the 
stacked vectors. Instead of a 3x3 system, we now have a 9x9 
system, but it’s still a linear system and the same rules apply 
to solving it. Throw Equation 22 into a linear solver, apply 
the individual f. vectors back to their appropriate objects, 
and you’ve got a constrained system. 

From here, it should be pretty clear how to extend this 
math to an arbitrary number of bodies and constraints. The 
A matrix and the associated vectors keep growing, but the 
structure is exactly the same. 


The Linear System Revisited 


4 said you can solve the Af. = b system using a generic lin- 
ear solver, which is true. However, there are more effi- 
cient ways of solving the particular matrix generated by our 
algorithm that take advantage of its special properties. Effi- 
ciency is incredibly important when doing constrained 
dynamics because linear systems such as Af. = b have O(n?) 
complexity in the general case, where n is the number of 
rows in the matrix. This means that every constraint equa- 
tion you add as an additional row makes the system much 
slower to solve. O(n?) complexity is not the kind of slowness 
that waiting for next year’s CPU can fix. 

The most important special characteristic of our A matrix 
is its sparsity structure. You can see this structure developing 
in Equation 22, and as you add more bodies and constraints 
you can see it even better: the constraint submatrices stay on 
the diagonal of the matrix and its neighboring columns, and 
the rest of the matrix is zero. This makes intuitive sense 
given that a constraint depends only on itself (which corre- 
sponds to the diagonal element) and its two constraint 
neighbors (the off-diagonal elements). The official name for 
the sparsity structure of the A matrix is “block tridiagonal,” 
for somewhat obvious reasons. What’s more, the A matrix is 
symmetric, although this fact is not completely clear from 
our derivation. And finally, it’s “positive definite,” assuming 
the constraint equations are well formed. A positive definite 
matrix is roughly analogous to restricting a real number to 
be greater than zero, rather than allowing it to be zero or 
negative. You can learn more about these characteristics in a 
good numerical linear algebra book. 

Taken together, these properties mean we can write (or 
download) a custom linear solver that will solve our systems 
in O(n) time. O(n) is definitely the kind of problem that 
AMD and Intel will make faster every year. 


Numerical Accuracy 


5 t’s really a shame that all of this math I’ve presented to 
you doesn’t actually work when you type it into the com- 
puter. Well, that’s a bit extreme, but the world of floating- 
point numerics is far removed from that of symbolic equa- 
tions, and we have to do a bit more work to get them to 
match up. 
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The major problem is that we’re 
using numerically computed forces to 
affect accelerations, which are then 
numerically integrated to find new 
positions. This algorithm has two big 
numerical holes in it. For starters, the 
forces we compute are not going to be 
exact because of floating-point errors 
accumulated during the formulation of 
the Af. = b system and its solution. 
This means the f. terms aren’t going to 
exactly enforce the constraint equa- 
tions when they’re applied in floating 
point. To compound matters, the 
integrator is going to introduce even 
more numerical errors, since we’re 
using forces to keep a position con- 
straint together. These two sources of 
error mean the objects will slowly drift 
apart. At first the errors will be small. 
If you subtract the positions of the 
two endpoints of a constraint, you'll 
see the result is not exactly the zero 
vector after a few steps. Eventually, the 
objects will have drifted far enough 
apart so you can see the gap. This 
is bad. 

There are many ways of dealing 
with this drift, and we don’t have the 
space to talk about any of them in 
depth. I favor a method called 
Baumgarte Stabilization, which basi- 
cally places tiny springs on the joints 
that are adjusted to suck up the 
numerical error as it develops. The 
springs don’t actually provide any 
physical support (the f. terms still do 
that), but they do a great job of keep- 
ing the joints together in the face of 
floating-point errors. The sample 
application implements Baumgarte 
Stabilization to fight the drift prob- 
lem. It’s easy to implement and it 
works well. 

Other methods include directly cor- 
recting for the drift in position space, 
and other techniques. Now that you 
know the math behind constrained 
dynamics, you'll have no trouble fol- 
lowing the numerical accuracy discus- 
sions in the books referenced on my 
web site. 


Miscellanea 


hew! That’s a lot of equations, but 

we've accomplished a lot. We’ve 
actually accomplished even more than 
we set out to, because all of this math 
is valid for completely general con- 
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straints. When I say general, | mean it 
in two ways: topologically and in terms 
of the joint types. 

Topologically, our constraint-cen- 
tric viewpoint means we can have as 
many constraints coming off a rigid 
body as we like. We’ll need to modify 
our notation slightly to support this, 
and the location of the elements in 
the Equation 22 matrix will change a 
bit depending on the interconnection 
of the bodies, but making an octopus 
would be no problem, even though 
the root body has eight constraints 
on it. 

As far as joint types go, Equation 3 is 
just one of an infinite number of accel- 
eration constraints this math can 
enforce. Again, pieces of the derivation 
change, but the overall structure stays 
the same, regardless of whether you’re 
simulating spherical joints such as 
Equation 3, or hinges, or prismatics, or 
whatever. Look at the references on my 
web site for books about writing differ- 
ent constraint equations, or give it a try 
yourself. The important thing to 
remember is to get it clear in your head 
what you'd like the joint to be, and 
then write down an equation that 


This key individual will 
concepts submitted by deve 





describes that joint. Differentiate it 
then plug and chug. 

Hopefully, with the general interest 
in physics for games that’s been grow- 
ing for the past few years, we’ll start to 
see a lot of special effects using real, 
consistent physics. Then, when every- 
body’s comfortable with the math and 
implementation issues, we can start to 
work on integrating physics with game 
play and game physics can finally live 
up to its potential. 
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iu ees sample app, articles, references, 
andmore: 
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by Toby Ragaini 





SHERON’S CALL is a statistical anomaly. In an industry 










where cancelled games and dashed hopes are the 
norm, this project seemed one day away from 
certain failure for nearly its entire history. And 
yet, thanks to the visionary foresight of a 
handful of people, a healthy dose of luck, 
and incredible conviction from both the development team and 
publisher, it made it to store shelves and has received a great deal of 
critical acclaim. 

In May 1995, I walked into a small suburban home in southern 
Massachusetts and met my new co-workers. Having left my previous job 
at a genetics lab, I expected nothing more than an interesting summer 
project as “A Game Writer.” Little did I realize what was in store for me 


and this start-up company called Turbine. 





Toby Ragaini leads Turbine Entertainment Software’s design team and was the lead designer of ASHERON’S 
CALL. He is currently working on Turbine’s next-generation massively-multiplayer game. 
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Having filled every nook of a residential home 
with PCs, an enterprising group of about ten 
developers was already busy working on the game 
that would one day become ASHERON’S CALL. 
Although not a single one of them had profes- 
sional game development experience, I was 
immediately impressed with their enthusiasm 
and dedication. After introductions, I was told to 
scrounge around for a desk. Upon securing an 
end table and a plastic lawn chair, I sat down and 
started meeting with various team members to 
figure out just what this game was all about. 

What was described to me was something that 
nearly every computer game geek is by now 
familiar with: a 3D graphical MUD. A persistent 
fantasy environment where hundreds of players 
could explore the land, defeat monsters, form 
adventuring parties, delve into dungeons, and 
complete quests. I’m not sure why anyone 
thought it was possible. We had no office, no 
technology to speak of, and no publisher. And I 
was being paid $800 a month. Yet from these 
humble beginnings, something truly wonderful 
was created. 

The development team was divided into func- 
tional departments. Tim Brennen, a Brown University 
dropout who had helped develop Windows NT as a 
Microsoft intern, led the engineering team and would go on 
to design the server, networking, and character database. 
Chris Dyl, a former physicist turned programmer, would 
develop the 3D graphics engine and server-side physics. 
Andy Reiff, also a Brown alumnus, would later round out the 
engineering leads as the game systems programmer, respon- 
sible for implementing all of the game rules systems and 
functional interactions in the game world. All of the game’s 
code would be developed from scratch. At the time, this was 
a fairly easy decision, since licensable game code was pretty 
much nonexistent in 1995. 

On the art team, Jason Booth, a music student with expe- 
rience using Lightwave, would take on the title of lead tech- 
nical artist. In this role, Jason bridged the gap between the 
art and graphics teams, ensuring that the art asset pipeline 
ran smoothly. Sean Huxter brought his substantial anima- 
tion and modeling experience to the team as the lead artist. 

My own contributions to the team were in the area of 
game design. As the project grew in scope, my role changed 
to become that of lead designer. Soon realizing the amount 
of work required to design a game with the scope of 
ASHERON’S CALL, I put together a team of designers that envi- 
sioned and documented the characters, monsters, history, 
and timeline of a fantasy world called Dereth. In addition, 
the design team spec’d all of the game rules and systems 
necessary to RPGs. 

Although the team had no professional game develop- 
ment experience, one invaluable thing that the team did 
have was experience playing MUDs and similar text-based 
Internet games. Although these games were comparatively 
simple, the game-play dynamics created in a massively-mul- 
tiplayer environment are extremely different from a single- 
player game. MUDs proved to be a very useful model for 
multiplayer gaming patterns. 


http://www.gdmag.com 





Dynamic load balancing on the server gave ASHERON’S CALL an expansive, 
seamless game world that required no load times. 


ASHERON’S CALL was initially designed to support just 200 
simultaneous players, each paying an hourly fee. Turbine 
would host the servers, which were originally going to be 
PCs running Linux. Although in today’s market, this sounds 
ludicrous, in 1995 this was in fact the standard premium 
online game model. Games using similar models, like 
Genie’s CYBERSTRIKE and America Online’s NEVERWINTER 
NIGHTS, were quite successful at the time. Based on this goal, 
the original schedule had ASHERON’S CALL shipping in the 
fourth quarter of 1997. 


What Went Right 


STAYING TRUE TO OUR ORIGINAL VISION OF THE GAME. 

@ AsHERON’s CALL was a ridiculously ambitious project 
for an unproven team. Yet despite this naiveté (or more like- 
ly because of it), the final product is frighteningly close to 
the original goal of the project. Of course during that time, 
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Shot of World Builder decorating an Empyrean ruin on the 
landscape in the desert. The pillars on that building are 
hand-placed, as was the portal and the lights that stand 


outside the door. 


Turbine learned lessons in feature cut- 
ting, scheduling risks, and compro- 
mise. But despite all the missed dead- 
lines, all-nighters, and other 
disappointments, we are able look back 
on our shared vision and take pride in 
that we achieved what we set out to do. 

Typically, there exists a master docu- 
ment that describes the overall game 
concept and goal. Although the docu- 
mentation at the inception of the game 
was in fact very sparse, what little that 
did exist described the fundamental 
architecture of the game, including its 
client/server model, dynamic load bal- 
ancing capabilities (described later), 
and 3D graphics. In addition, game- 
play details such as the alle- 
giance system, magic economy, 
and the emphasis on social game 
play are in my notes going as far 
back as 1995. The team internal- 
ized these goals, and a form of 
oral tradition maintained them 
in meetings. 

Although we didn’t know it at 
the time, ASHERON’S CALL would 
debut as the third massively- 
multiplayer online RPG amidst 
two strong competitors, ULTIMA 
ONLINE and EVERQUEST. We’re 
often asked if we made any dra- 
matic changes in response to the 
release of these two titles. In all 
honesty, the answer is no. If 
anything, these two products 
proved to us that our initial 
technical and game design deci- 
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Shot of the in-house dungeon creation tool. Once the dun- 
geon is laid out the decorating can begin. The panel to the 
right is a list of hand-placed objects in the current piece. 


Note the mine wheelbarrows and picks on the wall. 





sions were correct. Clearly, social game 
play helped drive the success of these 
games. This made our game’s social 
systems such as allegiance and fellow- 
ships all the more important. It was 
also obvious that immersion was criti- 
cal. Instability and pauses were the 
bane of massively-multiplayer games. 
In theory, the dynamically load-bal- 
anced servers would prevent many of 
these problems. 

In an industry that can be driven by 
holiday deadlines, marketing hype, 
and cutting corners, it’s refreshing to 
know that ambitious goals can still be 
rewarded. But it’s more than that. 
While we certainly could have created 


a less ambitious game, | believe it 
would have been a detriment to 
Turbine’s competitiveness as an inde- 
pendent development studio. 
ASHERON’S CALL might have shipped 
earlier had it been a LAN game ora 
series of connected arenas, but we 
would not have the innovative tech- 
nology and game design experience 
that today puts Turbine in such a desir- 
able competitive position in the indus- 
try. In this way, our team’s unwavering 
vision was handsomely rewarded. 
SECURING A PUBLISHING AGREEMENT 
@ with Microsort. In mid-1996, 
representatives from the newly-formed 
MSN Gaming Zone were booed by the 
audience of the first Mpath 





Shot of the landscape test program. Designers ran 
around the landscape off-line to see what had been 
added and how it looked. This is a shot of the obsid- 
ian plane with mushrooms and crystals, not to men- 
tion some creatures lurking near a mysterious 
power source. 





Developer Conference. Their crime 
was the prediction that hourly fees 
were dead and that flat monthly 
rates would become standard. Our 
business plan at the time counted 
on an hourly model, but we recog- 
nized the truth to the Zone team’s 
statement. At that year’s E3, we 
relentlessly pursued Jon Grande, 
product planner on the Zone, in 
order to pitch him our game pro- 
posal and show him our technolo- 
gy demo. At that time, the demo 
consisted of two PCs connected to 
each other. One was running the 
client software, complete with 3D 
graphics. The other was the server 
executable. The Zone team was 
very impressed, and scheduled a 
visit to our office (we’d since 
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Whatever the game, LicenseMusic.com has the perfect music. 


lets you instantly preview, download and license tens of thousands of 
music tracks. Be it Sunday afternoon or four in the morning, LicenseMusic.coms search 
and licensing engine makes it simple and convenient to find music for that alien attack, 
speeding car chase or Egyptian Tomb raid. No access fees to pay. No lawyers to hassle 
with. No salespeople to haggle with. Next time, put your game to music and mind to rest by 
visiting 'o) ams ohVarer=] UU aTe eo) g 


Just what you want to hear. 











Different types of combat were developed independently, causing complications. 


moved into an actual office space 
south of Boston). Soon after the visit, 
Microsoft agreed to enter into a pub- 
lishing agreement with Turbine, 
secured initially with a letter of intent. 
The actual contract arrived six months 
later, but the letter of intent granted us 
an initial milestone payment and 
enough certainty to schedule the mile- 
stone deliverables. This was the start of 
a long, sometimes tumultuous, but 
ultimately fruitful alliance. 

After we secured the contract, the 
division of labor was discussed. As the 
developer, Turbine was to design the 
game, engineer and implement all of 
the code, generate all art assets, create a 
QA plan, and perform testing on all 
game content. With its pre-existing 
Zone platform, Microsoft was responsi- 
ble for code testing, billing, and ongo- 
ing server operations. Fundamentally, 
this meant that while Turbine would 
create the game, the day-to-day opera- 
tions of the ASHERON’S CALL service 
would be entrusted to Microsoft. 

One thing that Turbine successfully 
negotiated for was the rights to our 
source code. Besides the team, we knew 
that our massively-multiplayer tech- 
nology was going to be our single most 
valuable asset. In addition, we agreed 
to a one-title deal that gave us the flexi- 
bility to pursue other development 
deals as opportunities arose. In this 
way, we ensured that Turbine would 
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remain independent and effectively in 
control of our own destiny. 

In many respects, Microsoft proved 
to be an ideal partner for Turbine. Like 
Turbine, the Zone was a start-up orga- 
nization, and was eager to prove itself. 
The Zone was pioneering a new type 
of business, with a business model 
new to Microsoft, and this placed the 
managers of the Zone in a position 
where they could afford to take risks. 
And while ASHERON’S CALL ultimately 
validated Microsoft’s belief in 
Turbine, at that point Turbine was 
certainly a risk. 

Besides the obvious funding issue, 
Turbine benefitted from its partner- 
ship with Microsoft in other ways. We 
had free access to Microsoft develop- 
ment tools like Visual C++, Visual 
SourceSafe, and a bug-tracking data- 
base called RAID. We learned a lot 
about professional software develop- 
ment from Microsoft as well, such how 
to create an efficient build process, 
manage code source trees, and orga- 
nize effective test cycles on the daily 
builds. Finally, we gained prestige by 
working with one of the most respect- 
ed software companies in the world. 
Having Microsoft as a partner gave us a 
lot of credibility and put us in a much 
better position to pursue funding and 
make critical hires, two incredibly 
important objectives for a small start- 
up company. 


REUSABLE ENGINE AND TOOLS. Mas- 
@ sively-multiplayer games 
require a fundamentally different 
architecture from that of single-player 
games, or even multiplayer LAN games. 
Beyond the graphics engine, user inter- 
face, and other elements of a typical 
game, persistent massively-multiplayer 
games generally require a centralized 
server, networking layer, user authenti- 
cation, game administration tools, and 
a host of other technologies. 

Early on, Turbine recognized that 
many of these technologies would be 
required by any massively multiplayer 
game, and could perhaps be general- 
ized enough that they could be reused 
in different massively-multiplayer 
titles. At the time, this was an unusual 
premise for a game developer; typical- 
ly, source code was thrown out at the 
end of a project, and the idea of licens- 
ing a 3D engine like Quake was still a 
long way off. From our perspective it 
just made good business sense to lever- 
age our R&D as much as possible. Since 
so much of our development budget 
was devoted to creating these key 
technologies, we made every effort to 
keep the technology modular and data- 
independent. 

This modular architecture has since 
proven to be a tremendous win for 
Turbine. We’ve been able to prototype 
new game concepts rapidly by chang- 
ing data while keeping the server exe- 
cutable nearly unchanged. Not only 
has this helped us get new business, it 
has also proven to be extremely useful 
for in-house play testing and construct- 
ing proof-of-concept demos. 

Currently we are investigating the 
potential of licensing our technology. 
While we continue to advance the code 
base, we have placed some emphasis 
on productizing the Turbine engine. 
From a business perspective, this is a 
very desirable source of revenue. We 
can leverage our R&D efforts and devel- 
opment costs, while advancing the 
engine that our own future products 
will use. 

In addition to the ability to reuse 
code, Turbine’s modular emphasis 
extended to the way content is created 
for the game world. As development on 
ASHERON’S CALL progressed, we quickly 
came to realize that populating a game 
world the size of Dereth was going to 
be a monumental task. By this time, we 
knew our competitors were hiring 
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Thanks to Pandemic Studios and technology from Intel and Digimation. 


ed- Ale (Jes) (ome) (lel (os-MUl-\-leMUIUli()ai-1-Mccleialare) (elem lamoleligm Bl-14 4 
at-i(elaWar-lalem =t-)at(-yde)a(-M i mcomelni-\ males Mie-lts\-Me-ii-miielel els 
Y-lergiilelialem—iital-lm@eet-ltl-M-M a lerg-tel|e)(-mele-|e)al(eme(-1f-11 mm (o)matcelb| 
can use the same technology in your own productions. 
Digimation has combined their experience in 3D software 
71am gi <-) e-de-lor-lt-]6)(-Me]e-] 0) sl (etm c-lei glace) (ele a comes g-t-1(-MilY-1 

Tate {tj el-at-t-| 0) (-Mcele)t-Mie)m@mel-lsil-Me(-\1(-) (0) 0|-1 eM] BM- | ail) t-- ale 

A" 3(=) os-}] {Mod g-t-] (0) g- Mam =t- [era (ole) Mi Mere) al t-|/ 41M le] |gei-Melele(-M-lale| 
ile) gl a"mil -s-me-t-1e hm CoM-llal-laler-mn (eo) 0] go) ge) (-\o1 


MultiRes gives game developers and artists 
the ability to create scalable 3D models that automatically 
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SubDiv RT provides users with a method of 
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model that is compact in size and then dynamically increase 


the resolution when it is displayed, providing a richer visual 
experience than the smaller sized model. 


SCALABLE 3D GRAPHICS 





Combine real-time skeletal deformation 
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be pre-authored with other software packages such as 
Character Studio” or Bones Pro 2 inside of 3D Studio MAX‘, 
or generated in real time by the Inverse Kinematic (IK) 
technology that is included in Animate RT. 


Particle RT gives content creators a 
complete particle system for generating thousands of 
particles in real-time. These particles can then be affected 
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different effects from billowing smoke to fiery explosions. 


This exciting real-time render technology allows 
users to transform and render their 3D models in 
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The Digital Animation Company 


www.digimation.com 
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teams to design individual 
levels and create content 
manually. This seemed less 
than optimal to us, and fur- 
thermore we didn’t have the 
resources to hire a large con- 
tent team. 

Instead, we created a series 
of world-building tools to 
maximize our efforts. The first 
kind of tool allowed artists to 
create vast chunks of game 
environment (represented as a 
grayscale height map) with 
each stroke of their brush. 
Random monster encounters 
and terrain features such as 
trees and butterflies could also 
be placed using this method. 

We also developed a tool called 
Dungeon Maker to create subterranean 
environments such as dungeons and 
catacombs. Early on, Jason Booth got 
sick of hand-modeling the complex 
level designs he was getting from the 
design team, so he and user-interface 
programmer Mike Ferrier created a 
level-building tool that used an intu- 
itive drag-and-drop interface. This 
allowed nontechnical designers the 
ability to create and instantiate dun- 
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.udio Sofrware ENGineer 
— Product Support 


Combine your love of video Games with your desire for PROGRAMMING Challenges! 
NINTENDO OF AMERICA, the world leader in video Game ENTERTAINMENT, Offers This 
EXCITING OpporRTUNiTy AT OUR Headguarters in REDMOND, WASHINGTON. 
Requirements: BS in Computer Science or equivalent; 7+ years of solid program- 
minG experience in C, C** under windows or embedded systems (consoles); knowledge of 
audio/video compression techniques (ADPCM, MP?, MPEG2), general MIDI and MIDI 
SEQUENCERS (Cubase, Cakewalk), audio topics (Dolby Surround, Dolby Digital, DLS, 
MPEG4, Direct Sound) and DSP (algorithms and programming); and excellent written, 
PERSONAL skills. Musical talent is a plus! 
Nintendo offers A COMPENSATION package that includes excellent b 
_ opportunity To work in a fun, fast-paced TEAM ENVIRO 
a _ COVER letter and Resume With salary REQUIREMENTS TC 
~ Human Resources Dept., Attn: CM/ASE 
WA 98073. E-mail: RECRUITER@ 


Each ASHERON’S CALL server had to support 3,000 concurrent 
players, minimum. 





geons quickly without taking up the art 
team’s valuable time. 

An offshoot of Dungeon Maker, 
World Builder, became a much more 
advanced tool by the time ASHERON’S 
CALL shipped. Using World Builder, 

a content designer could wander 
around the game world placing houses, 
decorations, and monster encounters, 
and even raise and lower the terrain. 
This proved to be an incredible time- 
saver, and the amount of landscape 


content we were able to gen- 
erate easily quadrupled. 

This kind of tool modulari- 
ty allowed us the ability to 
update the game world easily 
with new content, such as 
new monsters, quests, items, 
and adventure locations. 
Thanks to monthly content 
additions, ASHERON’S CALL 
“events” can propel an over- 
arching story forward and 
involves players in all areas 
of the games. So far these 
events have proved to be a 
huge success. Players feel like 
they are part of a living, 
breathing world, and are 
more likely to stay involved 
in the game for longer periods of time. 

PAINLESS LAUNCH. When the first 

@ few thousand players began 
pouring onto the production servers, 
we were certain that there would be all 
sorts of catastrophes. We had watched 
our competitors suffer similar calami- 
ties, and we had resigned ourselves to 
accept this rite of passage. To our sur- 
prise, nothing went wrong the first 
day. We were delighted by just how 
stable and uneventful the retail launch 
was. Everything went without a hitch. 

This stability was due to effective 
beta testing, intelligent project man- 
agement, and insightful data-center 
equipment deployment. Here’s how it 
worked. During beta, both Microsoft 
and Turbine testers submitted bugs 
into RAID. In addition, user-submitted 
bugs were tracked by the Microsoft 
team and were added into RAID if they 
were deemed important. Server perfor- 
mance metrics were one of the key 
goals towards meeting our shipping 
requirements. Each server had to 
maintain a minimum level of perfor- 
mance, given a concurrent user base of 
3,000 players. To meet this metric, a 
few changes were in order. The server- 
side physics was modified to use a 
more simplified collision model. In 
addition, a faster “clean-up” cycle for 
objects dropped on the landscape was 
implemented. Having made these 
changes, we were able to meet the 
aggressive server metrics and our serv- 
er software has since proved to be 
nearly bulletproof. In fact, for the first 
several weeks, the server software did 
not crash once, which was a major 
accomplishment considering the tech- 
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nical problems evident in 
other massively-multiplayer 
games. 

Our retail launch was a stag- 
gered affair. Initially, only two 
“enthusiast-oriented” retail 
chains received shipments of 
ASHERON’S CALL boxes. This 
allowed our die-hard fans from 
the beta testing program to get 
copies, but prevented the del- 
uge that would have occurred 
had we been in the larger, more 
mainstream retail stores. While 
it would have been exciting to 
see massive sales on day one, I 
believe that this gradual 
approach was a smart move. 

SEAMLESS ENVIRONMENT 

@ USING DYNAMICALLY LOAD-BALANCING 
SERVERS. One the most impressive fea- 
tures of the Turbine engine is the con- 
tinuous outdoor environment. This is 
made possible thanks to dynamic load 
balancing, which is a scalable server- 
side architecture. The easiest way to 
appreciate the need for dynamic load 
balancing is to consider the following 
scenario. 

Imagine a hypothetical game world 
that is divided into four servers, each of 
which corresponds to a geographic area 
in the game world. With a static server 
architecture, if everyone in the game 
world decides to go to the same area, 
that one server’s performance would be 
dramatically impaired, while the three 
remaining servers would effectively be 
idle, completely unaware of their over- 
taxed brother. 


Sesee sri yo eee 


World Builder let Turbine place monster encounters easily. 





Dynamic load balancing solves this 
overloaded server problem. Instead of 
assigning a static geographic area to 
each server, the individual servers can 
divide up the game world based on the 
relative processor load of each server. 
In the previous example, instead of 
remaining idle, all four servers would 
divide the load equally among them- 
selves, ensuring the most efficient use 
of the hardware’s processing capacity. 

Dynamic load balancing allows a 
very free-form environment where 
players can travel wherever they want 
with very few hard-coded limits. But in 
order for the graphics engine to accom- 
modate the seamless nature of the serv- 
er, we couldn’t allow a “level loading” 
pause typical in many 3D games to 
interrupt the game play. To avoid level- 
loading, the geometry team headed by 


This is a shot of the Banderling being animated. He is per- 
forming a large swing to the front, and is caught in mid- 


backswing. The weapon is rooted out of the scene when 
the animation is preprocessed, as is the floor. Note the 
movement path of the weapon as it strikes. 
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rendering engine that con- 
stantly loads data in the back- 
ground, and draws objects at 
far enough distances so as to 
minimize obvious “popping” 
effects and without having to 
rely on a fogging effect to hide 
the clipping plane. 


POOR SCHEDULING AND COM- 
@ munication. For most of 
its early history, ASHERON’S 
CALL was the victim of poor 
project management. During 
the last year of development, a 
management reorganization took place 
that salvaged the project. Depending 
on how far back you look at the sched- 
ules, ASHERON’S CALL was either one to 
two years late. This is attributable to a 
number of reasons, some of which | will 
explain momentarily. 

When Microsoft and Turbine entered 
into the development agreement, nei- 
ther side had any idea of the scope of 
the project. An initial list of milestones 
was drawn up by the Microsoft product 
manager and our development leads. 
Unfortunately, after the second mile- 
stone, deadlines were consistently 
missed. A lot of this was due simply to 
underestimating the time required for 
development tasks. This created a 
domino effect as we continually played 
catch-up, trying desperately to make 
up for lost time. 





motion graph shows the keyframes and the spline move- 
ment of the Banderling’s chest as he makes a swing witha 
weapon. 
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$3’s Diamond 

Monster Sound 
MX400 will rock your PC audio world. Based on ground- 3 
breaking technology from ESS and Sensaura, the Monster’ Me am ONY 
Sound MX400 adds a whole new twist to your gaming 
experience with scorching 3D positional audio, so now you hear sounds 
on a whole new axis—above and below you. And with true 
quad output and Dolby Digital surround sound* you create the ultimate 


PC home theater. Plus you can play, download, store and 
manage the hottest digital audio formats on the Internet or copy tracks 





from your CD collection to build your own high quality MP3 files! 
SO UP YOUR AUDIO WITH MONSTER SOUND MKD girly | in a class by itself! 


"Requires Delby Digital receiver 





Screenshot of Siave Zero. courtesy of Accolade. 
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Believe it or 
not, that's how 
many play dice 
every day. Which 
1s why we've 
created a set 
of real dice 
that work 
seamlessly with 
both computer 
and video games. 
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This schedule free-fall continued 
into 1997 and forced us to re-evaluate 
the feature set. Unfortunately, feature 
cuts were made without considering 
the impact on the playability of the 
game. Ultimately, most of these 
features were added back into the 
game anyway, which took additional 
time due to the reallocation of team 
resources. The lesson here concerns the 
value of effective scheduling. Identify 
the risky areas in your schedule early, 
figure out the dependencies, and make 
sure you pad the time estimates for 
tasks. 

Communication between Microsoft 
and Turbine was also a major factor. 
The teams were separated by about 
3,000 miles and three time zones. 
Although weekly conference calls 
were scheduled, they lacked the col- 
laborative mentality necessary for 
maintaining a successful relationship. 
E-mail threads were either ignored 
or else escalated into tense phone 
calls, and in some cases the bug- 
tracking database (RAID) was not used 
effectively. 

Clearly, everyone would have bene- 
fited from more face-to-face time. 
E-mail — and even conference calls — 
are poor media for managing new and 
sensitive corporate relationships, espe- 
cially ones between companies with 
such different corporate cultures. 
From a developer’s perspective, it’s 
always easy to blame the publisher for 
unrealistic expectations and bureau- 
cracy. What’s important to realize is 
that it is everyone’s obligation to com- 
municate expectations and problems 
before they escalate to the point of 
being a crisis. 

INEXPERIENCED DEVELOPMENT TEAM. 

@ None of the senior developers 
at Turbine (including me) had ever 
shipped a retail PC game. None. Many 
of the employees were students imme- 
diately out of college, or even college 
students completing a work-study pro- 
gram. This obviously was the source of 
several severe problems in the develop- 
ment of ASHERON’S CALL. 

It was neatly impossible for team 
leads to give realistic schedule esti- 
mates for tasks, since few of us had 
experience in professional software 
development. It was also initially diffi- 
cult to get different teams from the 
programming, art, and design depart- 
ments to communicate regularly with 
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Early early shot of a mock-up UI that 
had very limited functionality. Some 
of the buttons worked, but mainly 
this was a prototype pasted over the 
3D window, which was working at the 
time. The upper-left set of buttons 
were macros. The paper doll was 
hand drawn, and did not reflect the 
look of the character. 


Appearance 


This is an incredibly early shot of our 
Character Generator screen. Much of 
the interface has remained unchang- 
ed, but the same cannot be said of 
the faces. This was probably version 
one of the face images. Turbine has 
gone through a couple of versions 
since then. 


each other. The collegiate atmosphere 
made it very difficult for decisions to 
be made; meetings would happen and 
resolutions would seemingly be agreed 
upon, only to have those same ques- 
tions asked in a subsequent meeting. 
No one likes unnecessary bureaucracy 
and giving up creative freedom, but 
ultimately one person needs to be 
given the authority to make a decision 
and hold people to it. A good supervi- 
sor takes into account the opinions of 
everyone involved; design by commit- 
tee simply does not work. 

Obviously, having a seasoned and 
experienced development team has 
innumerable advantages. While it’s not 
critical that everyone on the develop- 
ment team have professional experi- 
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ence, at the very least team 
leads should have some form 
of professional experience. As 
it was, Turbine had to get by 
with raw talent, unabashed 
enthusiasm, and simply not 
knowing any better. 
a NO FEATURE ITERATION DUR- 
@ ING DEVELOPMENT. Many 
weaknesses Of ASHERON’S CALL 
at launch stemmed from the 
methodology we followed for 
feature completion. Features 
were scheduled by milestone 
and were expected to be com- 
pleted in their entirety before 
other features were worked 
on. While this approach may 
work for more typical soft- 
ware applications, PC games 
rely on a host of interrelating 
systems that cannot be implemented 
in a vacuum. 

An example of this involved our 
melee combat system. This game fea- 
ture was completely spec’d and imple- 
mented long before magic spells 
worked within the game, under the 
misguided assumption that it saves 
developer and test resources not to 
have to revisit completed features. 
Clearly, these two game systems 
needed to be tested and balanced in 
stages alongside each other, not 
independently. 

Another example of this problem 
occurred during beta testing. A mas- 
sively-multiplayer game cannot be con- 
sidered adequately tested until thou- 
sands of players have participated in 
the game world for at least a few 
months. The first time ASHERON’S CALL 
was exposed to this many users was 
when it went into beta testing. 
Unfortunately, we were placed in a 
code freeze situation during the beta 
test, and only the most serious bugs 
were fixed. 

Both Microsoft and Turbine recog- 
nized many serious game balancing 
problems during beta, but at that point 
it was extremely difficult to make 
changes. This can be attributed to our 
tight schedule, but earlier beta tests 
would have accelerated the bug-finding 
process and resulted in a better bal- 
anced game. On future projects, 
Turbine is deploying a more iterative 
implementation process where rapid 
prototyping and early play-testing is 
encouraged. 
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It was difficult to play-balance the game since that aspect of 
development took place after the code was frozen. 





AN AMBITIOUS PROJECT LACKING 
@ FUNDAMENTAL UNDERLYING TECH- 
NOLOGIES. As one of the first massively- 
multiplayer 3D games, ASHERON’S CALL 
was a bold undertaking. Several core 
components were still theoretical when 
the project was planned. Things like 
dynamically load-balanced servers and 
continuous, uninterrupted outdoor 
environments were still unproven con- 
cepts when we committed to them for 
ASHERON’S CALL. Furthermore, we had 
to create our own 3D graphics engine, 
a latency-friendly network layer, and 
physics and game rule systems that 
would all work within a client/server 
model. 

We learned very quickly why there 
hadn’t been a game like ASHERON’S 
CALL before us: It was damned hard to 
develop such a game. I don’t think 
committing to a less aggressive feature 
set was the right solution, though. 
Instead, we should have acknowl- 
edged up front that R&D efforts are 
fundamentally hard to schedule, and 
been more flexible with our develop- 
ment schedule. With this in mind, we 
could have created more realistic esti- 
mates and done a better job managing 
expectations within and outside 
Turbine. 

NO DOCUMENTED HIGH-LEVEL FEATURE 

@ STATEMENT. Because ASHERON’S 
CALL had such a long and evolving 
development cycle, it was difficult to 
keep all the documentation up-to-date. 
To compound the matter, the project 
never had an official feature set as part 
of the development contract with 





Microsoft. The technical 
design document process 
and high-level feature 
overviews were basically 
skipped. This created severe 
problems when it came to 
prioritizing which features 
were important. We con- 
stantly had to justify fea- 
tures, and we had no docu- 
mentation to fall back on to 
resolve our discussions. 

Without a high-level 
vision statement it was also 
very difficult to educate 
new employees about the 
game. There was a sort of 
oral tradition to initiate 
new employees that had 
been passed down for so 
long that it just became 
part of our company’s culture. This was 
partially possible because the concept 
of a 3D graphical MUD intuitively 
made sense to a lot of people. 
Unfortunately, it was very difficult to 
explain what ASHERON’S CALL was about 
to people who didn’t understand this 
concept or had their own ideas about 
how things should be done. Having a 
documented vision statement and a 
description of the high-level feature set 
is absolutely essential for any title. 


A Unique Company Resumé 


SHERON’S CALL was a tremendous 

learning opportunity for Turbine 
and Microsoft. Despite all the problems 
and setbacks, ASHERON’S CALL is a suc- 
cess story. The game has been well 
received by PC game enthusiasts as 
well as the majority of the game indus- 
try press. The fan support for ASHERON’S 
CALL is overwhelming, and players rou- 
tinely spend more than six hours a day 
logged into the game world. 

In addition, Turbine is now in a very 
desirable position, being one of only a 
handful of developers (and the only 
independent studio) that has success- 
fully created a massively-multiplayer 
title. Industry analysts predict that 
online games will be the fastest grow- 
ing segment of entertainment software. 
With its reusable architecture, robust 
toolset, and (now) experienced devel- 
opers, Turbine intends to remain at the 
forefront of massively-multiplayer 
gaming. @ 
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Play with more 
intelligence. 





microchip technology has transformed almost everything about home entertainment, 
making products better and smarter than ever. 


E The fun is back. Kids of all ages are into video games like never before. In fact, 






STMicroelectronics supplies billions of microchips for a broad spectrum of digital 
consumer products, particularly for advanced systems, such as digital cameras, DVD, 
HDTV, set-top boxes, and PCs. 


That makes ST a major player in the digital revolution. 





We put more intelligence into everything. 


ST Microelectronics (formerly SGS-THOMSON) « A world leader in semiconductors for consumer products, automotive, telecommunications, 
computer peripherals, industrial automation and control systems « Ninety-five locations on five continents « www.st.com 

































In anindustry where opportunities 
pass by before most knew they even 
existed, it’s crucial to never lose 
sight of where you want to be. 


Whether you hope to build a career 
with one of the video game industry’s 
premier companies orto create your 
own household name from scratch, 
it’s essentialto connect with people 
who can help you realize your 
potential. 


Interact is a multi-million dollar talent 
agency specializing inthe placement 
of individual game developers andthe 
representation of independent 
studios and interactive rights for 
many high profile licensed 
properties. We offer the most 
well-connected staffing 
network inthe game business. 
With over seven years inthe 
industry, we have the inside 
knowledge and experience to put 
you within reach of virtually any 
opportunity you seek. Put our 
resources to work for you. 
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“We want people who can break the rules." 
Artists, Programmers, Animators, Designers | 
Positions Available in Silicon Valley, San Diego and Chicago 


Check out hot job opportunities at midway.com 
see us.at the GDC in Booth 1835 


NEW from Coriolis Technology Press 


ISBN: 1-57610-425-7 
Price: $49.99 U.S. » $73.99 Canada 
Written for PC, Macintosh, and Unix 
platforms, this book uncovers object- 
oriented design, core design, gameplay, game balance, 
and provides real-life case studies. 


Ni\= 
3D GAN 
OuITH Crt ISBN: 1-57610-400-1 
Price: $49.99 U.S. » $73.99 Canada 


Learn to create sited — PC nae 


the power of DirectX. ieelsies a coward 
by Andre LaMothe and a full source code game engine. 


Books include CD-ROM packed with valuable ta6ls! 
Available at Bookstores and , 
Computer Stores Worldwide 


Telephone: 800-410-0192 
Fax: 480-483-0193 
International: 480-483-0192 
In Canada: 800-387-9776 


< 1999 The Coriolis Group Prices subject to change. GD100 1099 
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Programmers Designers World-builders Artists 


Knard, we play Hard, and we develop 
james in the world! 


Current project : 


“Duke Nuke Dianet a1 the Babes” 
“Dangertitt 


plus 2 “unannounced mays tation" Li1IES 


Attn: Human Resources | t 
7035 Grand National Drive » ai 
Orlando, FL 32819 | yar 
fax: 407.352.5571 | ae 
email: hr@n-space.com Mix. 
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BUILD THE FUTURE 1U0do 


Can you say Massively Multiplayer? 
interested in Broadband? 
nelp shape the future of interactive entertainment? 




















Sony Online Entertainment is looking for creative thinkers, 
visionary dreamers and committed enthusiasts to work with the 
hottest game brands online today: From JEOPARDY! Online and 
Wheel of Fortune Online to the ground-breaking EverQuest! 


At Sony Online Entertainment, we know how to satisfy people's 
passions for what they love most—Games! We work with the 
best in the industry, create the best games and have the best 
time doing it! 


We have immediate openings for talented individuals in 
Los Angeles and 


New York! © GaME DESIGNERS 








+ SOFTWARE ENGINEERS 





DATABASE ENGINEERS 


Unix SYSTEM ADMINISTRATORS 








ArT DIRECTORS 





GRAPHIC DESIGNERS 
>» PRODUCERS 


» ASSOCIATE PRODUCERS 






» INTEGRATION PRODUCERS 











LOOMS AAO RE SAE SESE SAE AT BEET 





-resumes@spe.sony.com 







ll to: Sony Online Entertainment Inc. 

_ Attn: Human Resources 

550 Madison Avenue, 7th floor | 
New York, NY 10022 





Sony is an Equal Opportunity Employer. | 
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training and your department 


is never under-staffed. 
Cc » s =. Bungie Software is seeking 


. PROGRAMMERS, MODELERS, 
Or go to Cc » _L.\- ANIMATORS, DESIGNERS ~ 
dice.com and C_ +» =) § .@— and TEXTURE ARTISTS. 
. “7 © "Texture Artist Position at Bungie West). 
actually find one. | 
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jobs. bungie.com 


GOC Job Fair Booth #1937. 


jobs@bungie.com 


ATTN: JOBS 


110,000 high tech jobs, including your next one. ge = “350 WiOMRois oh toot 


Chicago, IL 60610 
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HIGH VOLTAGE SOFTWARE 


A FULLY Y2K-COMPLACENT AND WHUP-ASS AUTHORIZED 
WORKPLACE CURRENTLY SEEKS THE FOLLOWING PERSONNEL: 


l Ss 
a 
'P, ~ P A. 
ARTISTS PROGRAMMERS PRODUCERS 


DISPATCH RESUMES TO HIGH VOLTAGE SOFTWARE 
2345 PEMBROKE AVE HOFFMAN ESTATES IL 60195 |\jctmmhbomsn : 


& ees 





ELECTRONIC TRANSMISSIONS: JOBS@HIGH-VOLTAGE.COM 
EDUCATE YOURSELF: WWW.HIGH-VOLTAGE.COM 
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NxN is a young, international company with offices in 
Moy alo(o)aMm\U(0lal(oa mm ac-latom- lace mey-lale- WU (ela) (et- B 
Leading game developers rely on our unique media asset 
management system alienbrain °. 


* @ #» 6&6 8 & 
+ + ee oe 


A Kom al=| om-\-m- (eal (=\\(omelelar-lanle)id(elemoy.<ey-lali(elame) (lami om-lfo 
looking for talented people in the following areas: 


& 
+s.* 


Sales Manager (Santa Monica, CA) 
Pre-Sales Engineer (Santa Monica, CA) 
Post-Sales Engineer (Santa Monica, CA) 

Associate Marketing Manager (Santa Monica, CA) 


e 
i 


NxN Software Inc., Santa Monica, CA 
e-mail: jobs@nxn-software.com, phone: (310) 477-0406 
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SKOTOS 


http://www.skotos.net 


Berkeley, California 

Skotos Tech is an online game company committed to 
creating a community of roleplayers and world builders. 
We will provide a massively multiplayer environment that 
allows players to explore many diverse worlds, and if they 
wish, themselves become world builders — without re- 
quiring knowledge of programming. 

Skotos Tech games are more then text-based adventure 
games or MUDs — our graphical clients offer tools to 
create deep and rich games without losing the technical 
advantages of a text-dominant medium. 

Though a startup company, Skotos offers excellent ben- 
efits, including medical, dental, and vision insurance; 
|00%-matching 401 (k) program: and stock options. 


WINDOwS CLIENT ENGINEER 


Windows engineer needed to develop text and graphic 
clients for online games. 
Applicant MUST have: 

¢ Extensive knowledge of Visual C++ & Microsoft 

Foundation Classes 

¢ 2+ years hands-on Windows GUI programming 

¢ Experience with ActiveX programming 

Engineer will design web-based ActiveX client from 
scratch, work with server engineering team on client- 
server protocols, and bring client design to completion. 
Candidates should be self-driven and independent, but 
able to work with the rest of the design team. Knowledge 
of TCP/IP. network programming, and fam with present- 
ing text a plus. Fam with MUD admin and dev also a plus. 


SENIOR SERVER ENGINEER 


Senior Server Engineer needed to develop server for on- 
line game company. 
Applicant MUST have: 

¢ BSCS (or equivalent formal engineering background) 

¢ Extensive experience with an object-oriented language 

¢ Solid understanding of object-oriented design 

¢ Solid understanding of fundamental data structures 

and algorithms 

Engineer will need to continue dev on an existing multi- 
player interactive fiction server, working with a team of other 
engineers associated with all aspects of the project. Applicant 
should work well with a team and have an interest in the 
English language. Fam with MUD admin and dev a plus. Ex- 
perience with the LPC or Pike a strong plus. 


BACKEND SERVER ENGINEER 


Backend Server Engineer needed to lead the development of 
a user accounting and online billing system. Will also lead 
development of a portal system for players, including email, 
simple web pages, buddy lists, calendars, etc. 

Applicant MUST have: 

¢ C programming experience 

¢ Database programming experience 

e Experience with shopping carts or other commerce 

programs 

e Experience with complex web design 

¢ Experience programming CGI on UNIX or Linux systems 

Engineer will assemble the backend accounting system for 
an online game company. This system will include database 
entries for all customers for both one-time and recurring pay- 
ments. System must also calculate royalty payments based 
on data gathered from the backend game server. 

Engineer will also create the software for a web-based 
community site, including personal portals, personal web 
pages, email, and calendars for all customers. This web- 
based community site must be able to gather data from 
the game server. 

Engineer must work well with a team of other program- 
mers. Familiarity with MUDs and LPC or Pike a plus. 




















For all positions: Applicant must be ready to relocate 
to the San Francisco Bay Area. | 
Contact Info: Qualified candidates should email re- 
sumes and cover letter in Word or ASCII text format, 
to jobs@skotos.net, or fax to 510/649-4034. Princi- 
pals only. Not a contract position. US or Canadian 
citizens or residents only. No phone calls please. Equal 
opportunity employer. 









Now Interviewing: 
¢ Art Director 


¢ Storyboard Artist 
¢ Character Designer 
* Photoshop/IIlustrator Artist 





* Modeling Technical Director 
¢ Lighting Technical Director 





¢ Personality/Behavior Scripter 


¢ Lead Character Animator-Maya | 


¢ Associate Character Animators 





























Dla During the Game... 


Developers Conference © 

Leave your résumé and VHS reel | 
or portfolio at the front desk of 
the San José Convention Inn 
455 South Second Street 
San José, California 95113 
attention Jordan Wong 


After the Conference 

Send your résumé, VHS reel 

or portfolio, and a cover letter 
. Artware, 99 Main Street 
Nyack, New York 10960 
attention Jordan Wong 
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VETERAN 


GAMERS 
PS2 TITLES 


Our Cool Publisher Clients 
JOB FAIR BOOTH eranek: 
# | 834 Lego 


MENaRs)| 
X@)5 

Our Cool Games 
NASCAR 2000 
mote) Me) me-\elr-laleaom 
MEXe(e(=10i meleyaey-1) 
Star Trek: DS9 
On-line Titles 


Our Cool Place 
Fun environment with awesome talent. 
Located in scenic Marin, just north of 
Sy la maclare vee) 


"Are You Cool Enough?" 
Senior or Lead Console Programmers 
Senior or Lead PC Programmers 
Producers or Associate Producers 
Art Directors and Lead Artists 
2D/3D Artists & 3D Animators 
Entry Programmers 
Interactive Writers 


Resume: Stormfront Studios, Attn:M. Daglow 
4040 Civic Center Dr., San Rafael, CA 94903 
Fax: (415) 461-3865 

email: mdaglow@earthlink.net 
www.stormfrontstudios.com 


STORMFRONT 
STUDIOS 








CAREERS 





Dear Professional Game Developer, 


If you're techni- 
cally astute and 
have a way with 
words, Game 
Developer maga- 
zine needs you. 
We're looking for 
feature articles 





On programming (graphics, Al, net- 
working, and so on), art and animation 
techniques, game design, audio tech- 
nology, testing and OA issues, and 
other relevant technical topics. We 
want to cover topics for variety of plat- 
forms, including the PC, console, 
arcade, and handhelds. Give back to 
the community some of the hard-won 
knowledge that you've learned! 


We're also on the prowl for post- 
mortems of recently completed 
games, always looking for people who 
are interested in reviewing game 
development tools, and constantly 
hunting down rabid “Soapbox” column 
writers. 


Please send your article abstract, 


outline, or wacky idea to: 


Writer's guidelines can be downloaded 


from Our web site ar 
www. .com/writguid.Atm 
Thanks, 


AnD 


Alex Dunne, Editorial Director 





game? 


NVIDIA. 


If you're looking for a way to take your “gaming” experience to the next level, there’s a 
good chance we've got the positions you need to see now. As the world’s leading supplier 
of performance 3D graphics processors, we're working on stuff that has to be seen to be 
believed. We offer very competitive salaries and benefits—and we’ve been know to have some 
serious fun too. This is a great opportunity to join the fastest-growing 3D company. Apply 
online at www.nvidia.com. Or e-mail your resume to: hr@nvidia.com. You can also fax it to: 
408-615-2800. If you want to get more out of your experience, you need to get into NVIDIA. 





e SALES 

e MARKETING € 

e HARDWARE ENGINEERING 

¢ SOFTWARE ENGINEERING 

° SYSTEM ENGINEERING 

e ARCHITECTURE V1 V I D I A.. 
°OA 


graphics 


© 2000 NVIDIA Corporation. All rights reserved. NVIDIA and the NVIDIA logo are trademarks of NVIDIA Corporation. 


United States e Canada e Mexico e France e Netherlands 


CANE 


MASTERING Sophisticated 


Animation, 
3D Matching 
and 

” » Motion Capture 


REPLICATION 
SCREEN PRINTING 


CD-VIDEO 


DVD-VIDEO 
OFFSET PRINTING 

DVD-ROM 
DVD AUTHORING for 


VHS CASSETTES 
AUDIO CASSETTES 


PACKAGING DESIGN 
ee 


. wee 1-800-433-3472 
foain ° United Kingdom e Canada e Mexico e France 


3D Studio MAX 


« Canaca e Mexico e Netherlands e United Kingdom e Spain e 
e uleds e WOphuLy pazLUp e SpueyayJaN @ Sa}e}S pajLup e 


afx.com 


1000 bux cn only Be each 
40 WEEKS 
27 ALL-NIGHTERS Also Providing services for: 


3HAIR COLORS 


: CHARACTER ANIMATIONS | 
(VIRTUAL) m Shaped CD's 


EXPLOSIONS | ga 
and m BusinessCard CD's e . 
FF Pr aasaioncetiie * 2 A 


oo EOLLER 
oy D REEL 


*) rile Ay ial “ , ' are 
rc... | 4x & 8x Blank CDR's 


Naw Machel o Gk ister 


AY sin acne Your partners in success! 
400 West Hastings Street, 


Vancouver, BC Canada V6B 1L2 Tel: (310) 827-7764 Fax: (310) 827-3744 
_- = ae = education E-mail: qr29@vis.com or call toll free at 1 888 965-4448 
Makeip tor Film setelevision = email: sales@lightninghill.com 








"TAR GE TZZPAVILION 


COMPUTER ARTS 
VIDEO/FILM 


BACHELOR of FINE ARTS 
MASTER of ARTS 


MASTER of FINE ARTS 








Game Development 


Interactive Design » Motion Graphics 
Sound Design + Video/Film 
2D Animation + 3D Animation 


Silicon Graphics, Windows NT, 
1D) GeV i e)at-W-lavem me) -lat-lall acekial 


After Effects, Alias, Animo, Director, 
D)folhe-|Msyaurel (oman lelurelialMmilivciag-lee)e 
Flint, Lightwave, Maya, Motivate, 
Nichiman, Painter, Photoshop, 
PlayStation Net, Yaroze, Renderman, 


Softimage, 3D Studio Max, and more. 


Savannah College 


Art and Design 


An International University for the Arts 


P.O. Box 3146 + Savannah, GA 31402-3146 USA 
1.800.869.SCAD 


info@scad.edu + www.scad.edu * www.ca.scad.edu 


Savannah College of Art and Design admits students 
of any race, color, and national or ethnic origin. 


Image: Hyun Huh; Seoul, South Korea; Alias/Wavefront Maya™ 


TREMOR 


ENTERTAINMENT 


VAVe= Tal are Weclaro.qom cal late owmel elt 


¢ Programmers 
e Artists 
e Animators 


¢ Designers 


eRepeersial @mm@r-iilielaalte 
(818) 729 0020 
www.tremor.net 





3D Modelers 

3D Animators 

Texture Artists 

Web Developers 

Content Engineers (TCL/Tk exp) 






; 
_Availabie Positions 


_Engineering 


3D Workspace/Human Factors 
Communications Development 
3D Software Development 


Forgive our enthusiasm, but we're 


Software Development 
Web Browser Development 
Technical Writers 


Do you think that the Internet could do with a facelift? Do you suffer from Windows rage? 
Do you want your internet experience to feel as good as the games you play? 


We do. Here at Muse Communications we are creating a platform 
that enables the creation and delivery of applications and Internet content 
that will make YOU excited. You're gonna dig this.... big time. 


Mea nles-{-Meve)aalanlelaycor-]t(e)at-mace) mele) e-lile)p 


1950 elkhorn court, san mateo, ca 94403 


Pe : fax: (650) 378 - 6339 jobs@musecorp.com www.musecorp.com 
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CONTINUED FROM PAGE 80 

Hollywood is often held up as a stan- 
dard by which we measure the progress 
of our own branch of the entertain- 
ment industry. The widely touted fac- 
toid that 1998’s computer and video- 
game revenues surpassed Hollywood 
box office receipts is one example. 
When you consider the total revenues 
from video rentals, licensing fees, and 
advertising, Hollywood is still way 
ahead — but our growth rate remains 


much higher than Hollywood’s, and 
shows little sign of slowing. It’s possi- 
ble to make a good case that at some 
point in the future, linear media such 
as film and television will be consid- 
ered a subset of interactive entertain- 
ment, just like how at first there were 
just movies, then “talkies” were intro- 
duced, and eventually “talkies” became 
“movies” and the old movies became 


“silent movies.” Perhaps what we now 
call movies will one day be called “lin- 


ears” or “branchless movies.” If that 
sounds ambitious now, at the 1988 
CGDC it would have been wild fantasy. 
Now, keeping our rate of growth in 
mind, even more seems possible. 

And so if it takes another ten years 
for Sid to get a chance to sleep in the 
Lincoln Bedroom (and scrawl “Lee 
Rules!” on the wall?) just remember 
you heard it here first. After that, who 
knows...the Nobel prize for interactive 
literature? B 





NAME 


Alias|Wavefront 

_Artware 
Ascension Technology Corp. 
Aureal Semiconductor 
Autonomous Effects 
BOPS Inc. 
Bungie | 
Cibro Technologies — 
Cinram . 
Conitec Datasysteins Inc. 
The Coriolis Group 
Dice.com 
Digimation 
Discreet 
E-Lysium Transaction Systems 
Giant Studios 
Global Majic Software 
Hewlett Packard 
High Voltage Software 
Ikarion Software GmbH 
Inoiz.com 
Interact Source 
LicenseMusic.com 
Lightning Hill Replicators 
LIPSinc 
Macrovision 
MathEngine 





NAME 


_ Midway Games 
_ Motek 
 Multigen 
Muse Corp. 
n-Space 
Newtek Inc. 








Nvidia 


Proksim Software 
RAD Game Tools 
Retro Studios 

$3 Diamond 


Sensaura CRL 
Skotos Tech Inc. 
SN Systems 
Sony DADC 
Sony Online 


Staccato 


Telekinesys 





Viewpoint Digital 


Authoring System 
for 3D Realtime Applications 


@ interactive 3D applications without programming! 

@ Create games, flight simulators, virtual exhibitions... 

@ Contains World + Model Editor and the A4 engine 

@ 3D action, adventure, role playing games included 

@ 6 degrees of freedom, mip and shadow mapping 

@ Particles, flare effects, fog, static + dynamic light sources 
@ D3D and software mode, 8, 16, 32 bit screen resolution 
@ Extremely fast rendering, even without 3D hardware 

@ 2D engine for menus, overlays, buttons, sprites, text 

@ Multiplayer via split screen, modem, network, Internet 
@ Cool scripting language for Al and user interface 

@ imports 3D$, MAP, MDL, PCX, BMP, WAV, MID, AVI 


1 =SCONITE 


Nintendo of America | 
Numerical Design Ltd. 


NXxN ae 


Savannah College of Art & Belen 


ST Microelectronics 
Stormfront Studios 


_ Tremor Entertainment 
_ Vancouver Film School 





B4)) Gunestaaio Cownnerci = $199 
3D GameStudio Professional ....$1:250 


(+ Multiplayer + CD-Audio + AVI-Player.+=Database Input) 


Infos, demos, ordering -> http://www.conitec.com 


1951 4th Ave, Ste 301 m= San Diego CA 92101 
Tel (619) 702-4420 wg Fax 702-4419 # www.conitec.com 














A Tale of Two GDCs 





White House! 


O.K., I’m making it up. But it didn’t 
sound entirely far-fetched, did it? After 
all, if movie directors and rock stars can 
be honored, why not Sid? He’s certainly 


| deserving when measured by hours of 


entertainment provided. More than 
deserving if quality counts, too. 

But our industry is still too young 
to achieve that level of recognition 
— for now. If your reaction was 
complete disbelief, just give it 
some time. 

Recently I offered to write this 
article about the interactive entertain- 
ment industry “coming of age.” But it’s 
too easy to make the case for putting an 
end to all those articles that begin 
“Although the computer game industry 
is still in its infancy...” At the very least 
we’re well into adolescence, as the 
success of Lara Croft attests. 

Then I had the good fortune to 
speak at the first Australian Game 
Developers Conference in Sydney. 
I was coming out for a week of 
work with Microforte, a game 
developer that was also co-sponsoring 
the conference, so combining the two 
seemed logical. 

I was also one of the 180 or so atten- 
dees at the second U.S. CGDC (now 
known simply as the GDC) in 1988 — 
not one of the two dozen people Chris 
Crawford invited to meet in his living 
room, but the first conference at a hotel. 
The similarities and differences between 
the Australian GDC and my first CGDC 
convinced me just how far we’ve come, 
as well as how far we have to go. 


| Noah Falstein runs The In 






EWS FLASH: Sid Meier will be one of the 
Kennedy Center Honorees next year and 


is invited to spend an evening at the 


There were around 250 attendees at 
this first AGDC, more than they expect- 
ed, and all the more significant consid- 
ering Australia’s population. A propor- 

tional attendance in the U.S. would 
be closer to 3,500 — the 
size of 


the CGDC 

just a few 
years ago. Back 
in 1988, it was 
impressive 
simply to : 
have 180 Gidueanetaat rotate 
game developers all in 

one place. The Australian conference 

was much more professionally orga- 
nized, too, borrowing a great deal from 


_ writing for both established and up-and-coming companies. When he isn’t jet-setting 


| around the world he can be found in Marin County, Calif. For contact info see his 


GAME DEVELOPER APRIL 2000 
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what has been refined through years of 
experience in the U.S. 

But more striking than the differ- 
ences were some of the similarities 
between the AGDC and that early 
CGDC. The large majority of the atten- 
dees at both were under 30 — not 
unusual in this industry, but it seemed 
the average age was a good five to seven 
years younger than the 1999 GDC. 
There was an air of enthusiasm and 
optimism once common in the U.S. 


and now increasingly 








a’ rare, no doubt due to 
IVF, -»< 


the increasingly cyni- 

cal and skeptical “old- 
timers” like me. There 
were several times 
when I cautioned 

impassioned young 

developers against 
some proposed course 
of game development 

with some variation on 

“that’s been tried repeatedly 
before and failed in these 
ways...” I think I saved some 

people considerable heartbreak, 
but there’s poignancy in realiz- 
ing that we’ve explored some 
frontiers and found nothing but 
badlands. It’s more fun when every 

horizon is virgin territory, full of 
promise, and sometimes the excite- 
ment of being an explorer is worth the 
attendant pain. 

Another measure of how far the 
industry has come was the very fact 
that I was at the conference in my 
capacity as freelance game design- 
er. The idea of flying someone 
out for a week of work from more 
than 7,000 miles away would have 
been fanciful 12 years ago and is rare 
even now, but to my delight is becom- 
ing more common. It seems the 
increasingly large and robust interac- 
tive industry has grown to the point 
of being able to support a growing 
group of freelancers similar to 
Hollywood’s ranks of writers, actors, 
and technicians. 

CONTINUED ON PAGE 79 


http://www.gdmag.com 














Maya for only $3,995. Imagine that! 


For a limited time 3D Studio Max users can purchase their first seat of Maya Complete for only $3,995 USD. 
Visit or call 1.800.447.2542. 


Alias| wavefront tA Yo 





Offer valid for all Max users with current v Offer valid until May 








first seat of Maya Complete 1 US dollars and may va 
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The Best in Game Development Technology! 
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